> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tachyon.pe/llms.txt
> Use this file to discover all available pages before exploring further.

# Roadmap: where the protocol is going

> What's live today, what's changing next, and why. Written for integrators who want to know what to build against vs what's coming.

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:

| Data                                      | Primary source            | Backup source                                             |
| ----------------------------------------- | ------------------------- | --------------------------------------------------------- |
| Intent + permit (encrypted)               | Relayer's durable storage | Periodic on-chain commitment proves existence + timestamp |
| Public outcomes (solver pull, settlement) | Source chain              | Always replayable                                         |
| Recipient keys                            | Enclave                   | User 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.

## Related

* [Architectural alignment](/concepts/overview) for how v1 composes on Canton
* [Privacy guarantees](/concepts/privacy-guarantees) for what's revealed at each step today
* [Relayer HTTP API](/api/relayer) for the endpoints live now