Trident at a Glance
Trident is a cross-chain liquidity rail. Deposit assets on one chain, spend them on any supported chain. No bridging, no pre-funding, no idle capital.
It works in two modes:
- No-Leverage: source your own liquidity — move what you already deposited to the chain where you need it. No borrowing.
- Leverage: source liquidity you don’t currently hold — Trident fronts it on the destination chain so you can execute immediately; if the destination action fails, nothing moves.
Who it’s for: market makers, solvers, and apps that need assets everywhere without juggling balances and routes.
How It Works
Section titled “How It Works”Traditionally, if you operate across multiple chains you need liquidity pre-positioned on each one. A market maker filling orders on Base, Optimism, and Arbitrum needs separate pools of capital sitting idle on all three. Trident removes that constraint: deposit once into a Trident vault, and that liquidity becomes available for delivery on any supported chain.
Trident is not moving your tokens from chain A to chain B. Instead, the Trident contract on the destination chain delivers funds locally by borrowing from Aave V3 and transferring them to the recipient. Your deposit on the source chain serves as backing. Circle CCTP settles the USDC collateral between chains under the hood.
The Flow
Section titled “The Flow”Your Chain (Arbitrum) Attester Destination (Base) | | | 1. deposit() ----------------->| | | observes, | | finalizes | | | | 2. spend request ------------->| | | validates, | | signs | |<---- attestation -----| | | | | 3. | | execute(attestation)-->| | | | | | mint USDC (Circle)-->| | | supply to Aave ----->| | | borrow token ------->| | | deliver to recipient>| | | | balance debited <-----------| |- Deposit: you call
deposit()on the Trident contract on your chain. Tokens go into the vault. The attester observes the deposit and finalizes it — your balance is now spendable on any supported chain. - Spend request: when you need funds elsewhere, you submit a spend request to the attester. It checks your balance and signs an attestation authorizing the destination contract.
- Execution: the attestation is submitted on the destination chain. The Trident contract mints USDC via Circle CCTP, supplies it to Aave as collateral, borrows the requested token, and delivers it to the recipient — one transaction.
If anything reverts on the destination, nothing moves. Your source balance stays intact.
Why This Matters
Section titled “Why This Matters”- One deposit, every chain: No need to split capital across chains. Deposit on Arbitrum, deliver on Base, Optimism, Ethereum - wherever Trident is deployed.
- No bridging: The recipient gets native liquidity on the destination chain, sourced from Aave. There is no token bridge or wrapped asset involved.
- Atomic delivery: The borrow-and-transfer happens in a single transaction. If your downstream action (a swap, a settlement, a fill) fails, the whole thing reverts.
- Capital efficiency: Instead of idle funds on five chains, you maintain one pool of capital and deploy it where needed, when needed.
Architecture
Section titled “Architecture”Integrator (Rust SDK) | |--- gRPC ---> Attester / Delivery Service | | | |--- signs attestations | |--- estimates fees | |--- tracks balances | |--- RPC ----> EVM Chains | |--- Trident Contract | |--- deposit() | |--- tridentSpend() | |--- Circle CCTP (USDC minting) |--- Aave V3 (supply + borrow)Attester/Delivery Service: Validates spend requests, signs attestations, tracks cross-chain balances. Communicates via gRPC.
Querier Service: Read-only API for deployments, balances, spend history, and lending positions. Same gRPC endpoint as the delivery service.
Trident Contract: Deployed on each supported chain. Holds deposited tokens, executes spend attestations by minting USDC (via Circle), supplying collateral to Aave, borrowing the target token, and transferring it to the recipient.
Key Concepts
Section titled “Key Concepts”Domain: A u32 identifier for each supported chain, aligned with Circle CCTP domain IDs.
Spend Intent: A request to move tokens from one domain to another. Includes spender, source/destination domains and tokens, recipient, amount, max fee, and an anti-replay salt.
Attestation: A signed payload from the attester authorizing the destination Trident contract to execute the spend. Contains the Circle Gateway attestation for USDC minting and the Aave borrow parameters.
Finalization: After depositing, you must wait for the attester to observe and finalize the deposit block before the balance is spendable. Finalization time varies by chain.