Integration starts by defining what is public, who can move funds and how each result will be verified. This is an interface proposal, without an active service.
Intents
An intent describes the order a user would like to execute. The format below is a study example; this site does not accept orders or request signatures.
{
"project": "tokash",
"network": "solana",
"side": "buy",
"amount_base_units": "250000",
"max_slippage_bps": 150,
"route_depth": 3,
"settlement_address": "<destination network address>",
"expires_at": "<expiry in UTC>",
"nonce": "<unique identifier>"
}Expiry, network, amount and destination would need to be included in the signed data. An implementation must prevent order replay and validate each asset's units.
Proposed API
The names below document possible responsibilities. They are not available endpoints and must not receive funds or wallet data.
quote_route(side, amount, depth)
// Fee and time estimate, with a defined expiry.
submit_intent(intent, signature)
// Validate the signature and order limits.
batch_status(batch_id)
// Execution, expiry or failure status.
integration_health()
// Accessible networks and settlement capacity.An active API would need to publish its address, authentication model, limits, data policy and failure handling. None of these can be inferred from the Tokash name.
Custody
Tokash does not receive or hold assets on this site. Before routing is implemented, the architecture needs to answer:
- Who controls funds at each step?
- Who can change or cancel an order?
- How does a user recover funds after a failure?
- Which guarantees are checked by code, and which depend on operators?
A wallet quorum, if adopted, would need implementation and auditing. The project has no active quorum or announced operators.
Settlement
A Solana order and a ZEC transaction are events on separate networks. Taking inspiration from Zcash does not allow an SPL token to settle directly to a Zcash address.
A future integration would need to define assets, conversion, custody, confirmation criteria and refunds on failure. Transparent and shielded addresses also require specific handling.
What “linked to Zcash” means here
A conceptual reference to privacy. It is not a token redeemable for ZEC, a ready-made bridge or a promise of a ZEC price peg.
Implementation criteria
- Choose an architecture and document its trust model.
- Test signatures, expiry, order replay and settlement failures.
- Separate Solana's properties from those of shielded Zcash transactions.
- Publish official contracts and addresses only after validation.
- Submit components that move funds to security review.
Reference material: Orchard and keys and addresses. See also the proposed architecture.