Skip to main content
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. 
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.

​
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

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, that’s a documentation gap.

Privacy guarantees

What’s private, what’s public, and what threats Tachyon defends against.