> ## 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. # Mental model > The five concepts you need to integrate Tachyon: intents, solvers, stealth addresses, viewing keys, and settlement. You can integrate Tachyon by understanding five concepts. Everything else is a protocol internal. ## Intent An **intent** is a signed message describing what your user wants to happen. You supply the parameters; the SDK (when shipped) or your own code constructs the on-chain `createIntent` call and the encrypted recipient bundle. ```ts theme={null} const params = { sourceChain: "base_mainnet", destChain: "horizen_mainnet", tokenIn: USDC_BASE, tokenOut: USDC_HORIZEN, amountIn: 1_000_000_000n, minAmountOut: 999_000_000n, deadline: Math.floor(Date.now() / 1000) + 3600, recipient: "0xRecipient...", }; ``` An intent is a **request**, not a transaction. The protocol decides who fulfills it and how; you only express the desired outcome. When the intent is created on source chain, the contract emits: * The **solver-facing parameters** (tokens, amounts, reward, deadline, destination chain), readable by anyone * The **encrypted intent** containing recipient info, only recoverable by the relayer's key This encrypted blob on-chain is the recovery anchor: if the relayer is ever lost, its holder can recover the intent state from on-chain data. That's why the intent submission itself is an on-chain call in the live protocol today. We're moving to an off-chain intent model where the sender doesn't call a source-chain contract at all to submit. Recovery moves to signed durable storage plus periodic on-chain commitments. See the [roadmap](/concepts/roadmap) for the full picture and timeline. ## Solver A **solver** is a network participant that fulfills intents by fronting capital on the destination chain. You never interact with solvers directly. Solvers see intents in two phases: 1. **Pre-bid broadcast (plaintext, batched)**, the relayer announces rate, token pair, fees, and aggregate amounts from a **batch** of intents to all solvers. No sender, no recipient. Solvers choose to fill some portion of the batch. 2. **Post-bid reveal (re-encrypted, per-solver)**, when a solver bids to take a portion, the relayer re-encrypts the matching recipient info + permit signatures to that solver's keypair. Only that solver can decrypt it. Other solvers in the batch see nothing about that fill. This is why per-intent amounts, recipients, and sender↔recipient linkage stay confidential from observers and from solvers that didn't win that fill. Solvers can **partially fill** a batch. Observers can't see which individual intents got filled because fills are drawn from the aggregate batch, not from single intents. ## Stealth address When a solver fulfills an intent, it sends funds to a **stealth address** on the destination chain, a fresh, single-use address derived for that specific delivery. Each intent gets a different stealth address, so observers cannot link multiple deliveries to the same recipient. The recipient controls the stealth address via their viewing/spending keys (held by the relayer on their behalf after registration). A Safe is deployed at the stealth address and funds are swept through it. ## Viewing key A **viewing key** is what lets a user see and claim funds delivered to their stealth addresses. The relayer generates the key material on `POST /recipient/register` and holds it (alongside the user's spending key) for signature-gated access. As an integrator, you treat access to these keys the way you treat any other user key material: require the user's wallet signature for every read or sweep operation. Without a valid signature, the relayer won't release the stealth key. Losing access to the wallet that proves ownership means the user loses visibility into incoming Tachyon transfers. The funds at stealth addresses still belong to them on-chain, but they can no longer prove ownership to the relayer. ## Settlement **Settlement** is the moment funds are delivered at the destination chain. There are two transaction hashes in the lifecycle: * `solveTxHash`, the solver's delivery on the destination chain * `settleTxHash`, the relayer's final settlement on the source chain (releases the solver's reward) Settlement is typically near-instant. If a solver fails to deliver before the deadline, the user is refunded through an on-chain escape mechanism on `BridgeIntentV2`, no funds are at risk. ## Putting it together ```mermaid theme={null} sequenceDiagram autonumber participant App as Your App participant Bridge as BridgeIntent (source) participant Relayer participant Solvers participant Dest as Destination chain App->>Bridge: createIntent(tokens, amounts, reward, destChain, ...) Bridge-->>Bridge: emit(solver params + encrypted intent to relayer key) App->>Relayer: POST /store-recipients (encrypted recipient bundle) Relayer->>Solvers: batched plaintext broadcast (rate, token, fees, totals) Note over Solvers: pick a portion to fill Solvers->>Relayer: bid Relayer-->>Solvers: re-encrypt recipient + permit for winning solver Solvers->>Dest: deliver to stealth address(es) Solvers->>Relayer: proof of fulfillment Relayer->>Bridge: settle (release solver reward) ``` What integrators see directly: the `createIntent` call, the encrypted `/store-recipients` submission, and status polling on `/intent-details/:intentId`. Everything between is protocol-internal. ## What you don't need to think about Protocol concerns that do not appear in your integration: * How the pre-bid batch broadcast is constructed * How re-encryption to the winning solver works * How solvers are selected within a bid * How liquidity is sourced or rebalanced * The on-chain escape mechanism internals If you find yourself needing to understand any of these to ship, [open an issue](https://github.com/tachyonpe), that's a documentation gap. What's private, what's public, and what threats Tachyon defends against.