How It Works
Architecture, bridge flow, and the cryptography behind it.
Architecture
Source chain
Deposit on source
Bridgeless L1 (Cosmos SDK)
Validate + sign
Destination chain
Withdraw on destination
Bridge Flow
User locks assets on source chain
- EVM: depositERC20() or depositNative() on bridge contract
- Bitcoin: Send to TSS address with OP_RETURN memo
- Solana: SPL transfer with metadata
- TON: Jetton transfer with message payload
- Zano: burn_asset with memo + point_tx_to_address
Bridge core validates the deposit
- Checks source chain via RPC
- Confirms required block confirmations
- Records deposit on Bridgeless L1
TSS network produces withdrawal signature
- Parties reach consensus on what to sign (acceptance phase)
- T-of-N parties collectively sign (signing phase)
- No single party ever holds the full private key
- Result stored on Bridgeless L1 (finalization phase)
Assets released on destination chain
- EVM/Solana/TON: User retrieves signature, submits withdrawal tx
- Bitcoin/BCH/Zano: Network broadcasts automatically
Threshold Signatures Explained
Single Custodian
One company holds the keys. If they get compromised, all funds are gone.
N-of-M Operators
N known parties each hold a key. If enough of them collude or get hacked, funds are gone.
Threshold Signatures
The private key never exists as a whole. Each validator holds a share. T-of-N shares needed to sign. Compromise one validator and nothing happens. Key shares are reshared when validators rotate.
Chain-Specific Details
Bitcoin & Bitcoin Cash
Deposits are sent to a TSS-controlled Bitcoin address with the destination encoded in an OP_RETURN memo. The TSS network holds the keys and broadcasts withdrawals automatically. UTXO consolidation prevents dust buildup.
View full integration docs →EVM Chains (Ethereum, Base, BNB)
Upgradeable bridge contracts handle deposits for ERC-20 tokens and native coins. Replay protection via transaction hash and nonce tracking. On withdrawal, the user submits the TSS-generated signature on-chain.
View full integration docs →Solana
SPL token deposits include destination details in the transaction metadata. The bridge program validates each deposit against the Solana ledger before processing.
View full integration docs →TON
Supports both Jetton tokens and native TON coin deposits. Bridge metadata is carried in the message payload and verified by the contract before processing.
View full integration docs →Zano
Privacy-preserving integration. Assets are burned on Zano with destination info attached, then minted on the target chain. Zano burns are irreversible, making the flow one-directional per transaction.
View full integration docs →