Two networks. Two responsibilities. An integration needs to define the boundary between them. This page describes components to evaluate; it does not present an operational Tokash node network.
The role of each component
| Component | Intended role | Status |
|---|---|---|
| Solana token | Record Tokash balances and transfers. | Unpublished |
| Solana RPC | Read state and submit valid transactions. | Not configured |
| Route coordinator | Validate intents and track execution. | Conceptual |
| Zcash client or node | Validate Zcash network data in a future integration. | Under evaluation |
| Cross-chain connection | Define conversion, custody and settlement. | Not implemented |
No RPC address, reserve balance or block height is presented as live data.
Why a node is not enough
Running a Zcash node can help verify the Zcash network. It does not hide a Solana token's transfers, convert that token into ZEC or create a redemption mechanism.
The choice between a full node, light client and external services should account for verification, availability, metadata and custody.
What to study in Zcash
| Area | Reference | Integration question |
|---|---|---|
| Proofs | Orchard · ZIP 224 | What statement needs to be proved? |
| Addresses | Keys and addresses | Which receivers and formats will be accepted? |
| Validation | Zebra · source code | How will Zcash state be verified? |
| Launch | Create a coin on Pump | What data and pair will be set before creation? |
Before activating any connection
Publish the trust model
Describe who can sign, move funds, retain data and stop operation.
Test real failures
Simulate outages, reorgs, expiry and confirmation differences between networks.
Validate the recovery process
Define how a failed order is cancelled and how funds are returned.