Skip to main content
The integration story in the rest of these docs describes what’s live today on Horizen and Base mainnet. This page is the forward-looking view: what changes next, what stays, and why.

​
Today (v1)

Intent submission is a two-step flow:
  1. Sender calls BridgeIntentV2.createIntent on the source chain. This is a normal on-chain transaction with the public solver-facing fields (tokenIn, tokenOut, amountIn, minAmountOut, reward, destChainId). The contract also emits an encrypted blob in the same event that only the relayer key can decrypt.
  2. Sender POSTs the encrypted recipient bundle to the relayer via /store-recipients.
Why the intent itself is on-chain in v1: the encrypted event blob is a recovery anchor. If the relayer’s state is ever lost or compromised, anyone holding the relayer key can replay the source chain, decrypt blobs, and reconstruct every intent ever submitted. It’s a cheap way to make the protocol state unilaterally recoverable from public data without giving up per-intent privacy. The trade-off: the sender’s action is visible on the source chain with its token pair and amount, even though the recipient stays encrypted. That’s visible before the relayer or any solver has even touched the intent.

​
Next (target model)

We’re moving toward off-chain intents. The sender never calls a source-chain contract just to submit an intent. Shape:
  1. Sender signs an intent off-chain (EIP-712 or equivalent).
  2. Sender signs a permit (EIP-2612 on EVM, analogous primitives elsewhere) authorizing the solver to pull amountIn + reward from the sender’s address when the winning bid comes in. The permit is scoped to the intent hash so it can’t be replayed on a different intent.
  3. Sender encrypts both (intent + permit) and POSTs to the relayer. Nothing hits a source-chain contract at this step.
  4. Relayer broadcasts a batched plaintext summary to solvers (rate, token pair, fees, aggregates; no per-intent recipient).
  5. Winning solver receives the recipient bundle and the permit under re-encryption to their own key.
  6. Solver presents the permit on the source chain to pull funds, delivers on the destination chain, and submits the fulfillment attestation.
  7. Enclave attestation is verified on-chain before the solver’s reward is released.
On-chain footprint per intent drops to: one permit-pull transaction (by the solver) + one settlement transaction. The sender never directly touches a Tachyon contract.

​
What the target model improves

  • Sender is not linked to the protocol action on-chain. The permit sits in the intent envelope until the solver pulls. An observer watching the source chain sees the solver making a standard transferFrom, not the sender signalling “I want to use Tachyon”.
  • No per-intent gas for the sender. Submitting an intent is a signature, not a tx.
  • Faster. No wait for source-chain confirmations before the auction starts.
  • Same guarantees. Re-encryption to the winning solver, enclave attestation on settlement, solver-funded liquidity, escape path on solver failure. All unchanged.

​
How recovery works without the on-chain blob

We keep the relayer-loss recovery property with two off-chain mechanisms:
  • Signed durable storage. Relayer writes every accepted intent + permit, encrypted to the relayer key, to append-only storage the relayer key-holder can always read back. Functionally the same as the on-chain blob, without the gas cost and without broadcasting the sender’s intention.
  • Periodic on-chain commitments. At an interval, the relayer publishes a single commitment (hash) of the batch of intents seen in that window. Lets anyone prove that a given intent existed at a given time, without publishing the intent itself. This is a public-good anchor: it keeps the network’s honesty externally verifiable even if the relayer’s off-chain storage is ever questioned.
Recovery model:
DataPrimary sourceBackup source
Intent + permit (encrypted)Relayer’s durable storagePeriodic on-chain commitment proves existence + timestamp
Public outcomes (solver pull, settlement)Source chainAlways replayable
Recipient keysEnclaveUser re-registers with wallet signature
So the “relayer key can replay chain state” property from v1 becomes “relayer key can replay its own durable storage, and anyone can verify it didn’t drop intents by checking the on-chain commitment stream.”

​
When

Target model ships as part of the solver SDK release (roughly M5 of the Canton grant timeline). V1 on-chain intent flow remains supported during and after the transition so existing integrations don’t break.

​
What integrators should do today

Build against v1. Every docs page labelled for today’s integration is correct. When we ship the target model, the SDK surface stays the same (submit(params, wallet)) and the underlying path swaps from “createIntent + store-recipients” to “signed intent + permit”. Your integration code doesn’t rewrite. Direct HTTP integrations will get a deprecation window on createIntent before the target model becomes the default.