Skip to main content
This page is what you tell your users when they ask, “how private is this, really?”

What’s private

The protocol guarantees these properties for every intent:
  • Sender ↔ recipient linkage, no observer (including solvers that didn’t win the fill) can tell which recipient received which sender’s funds.
  • Per-intent recipient addresses, never posted in plaintext on-chain; stored encrypted in the relayer and re-encrypted to the winning solver only.
  • Per-intent amounts, individual intents are batched with others before being broadcast to solvers, so observers cannot attribute an amount to a specific intent.
  • Permit signatures, transferred to the winning solver under re-encryption; never readable by non-winning solvers.
  • Recipient destination chain linkage, each intent settles to a fresh stealth address on the destination chain; observers cannot link multiple deliveries to the same recipient.

What’s public (on the relay layer)

Solvers need enough information to decide whether to fill. The relayer broadcasts these to all solvers in batched plaintext:
  • Token pair (source token, destination token)
  • Exchange rate / price implied by the batch
  • Fees / reward pool the batch is paying
  • Aggregate amounts across the batch (not individual intent amounts)
  • Source + destination chains
A solver can partially or fully fill a batch. They cannot tell which individual intent inside the batch they ended up filling until they win a bid and receive re-encrypted recipient info.

What’s public on-chain

Observers on source and destination chains see:
  • The fact that createIntent was called on source, including the token pair, amounts, and destination chain ID (public arguments of the contract call)
  • An encrypted blob in the same event containing recipient data, recoverable only by the relayer key. This is the on-chain recovery anchor: if the relayer is ever compromised or lost, the blob lets the key holder re-trace all intents from on-chain history.
  • A settlement on the destination chain to a fresh stealth address
  • Approximate timing of each action (bucketed, not exact)
What’s necessarily public: the sender’s on-chain action (calling createIntent) is visible on the source chain. Tachyon hides the linkage to any specific recipient or amount, but cannot retroactively hide the fact that the sender interacted with the protocol at all.

What observers cannot derive

Even given everything public above:
  • The recipient of any specific intent
  • Which amount belonged to which intent within a batched broadcast
  • That multiple deliveries to the same recipient came from the same sender
  • The permit signatures used for the source-chain token pull (those only exist in the re-encrypted solver bundle)
Each intent settles to a fresh stealth address. Two payments to the same user appear as two unrelated addresses receiving funds.

Threat model

ThreatTachyon’s answer
Chain-watching adversarySees createIntent calls with public token/amount fields and an encrypted blob they can’t decrypt. Destination chain shows only fresh stealth-address activity.
Solver trying to read intents they didn’t winSees only the batched plaintext broadcast (rate, token, fees, aggregates). Cannot decrypt per-intent recipient info without a bid win.
Solver trying to leak intents they did winThe solver gets recipient info under re-encryption to their own keypair. Misbehavior is detectable and economically penalized at settlement.
Operator trying to read intentsPlaintext recipient info lives only in the relayer between /store-recipients and the bid-win re-encryption. Wallet signatures are required for any user-side access (register, derive-key, list).
Protocol halt / relayer compromiseThe on-chain encrypted blob in every createIntent event lets the relayer-key holder reconstruct intent state from on-chain history. The BridgeIntentV2 escape mechanism also returns user funds if no settlement completes.
Future advances in cryptanalysisHybrid cryptography designed to resist both current and future (including quantum) attacks.

Selective disclosure

Confidentiality and compliance aren’t opposites. A user (or the relayer on their behalf, with the user’s wallet signature) can produce a scoped, verifiable record of:
  • A single intent (for accounting or tax)
  • A range of intents over a period
  • Proof of receipt for a specific delivery
The disclosure is scoped, granting visibility to one intent does not grant visibility to others.

Set up viewing permissions

Add auditor or counterparty viewing access at intent submission time.

What integrators should not claim to users

Be careful not to overstate the guarantees.
Tachyon does not retroactively hide on-chain actions. A user’s call to createIntent is visible on the source chain, including the token pair and the amount being committed. Tachyon hides the recipient and the linkage between sender and recipient, not the fact that the sender interacted with the protocol.
If your product surfaces a “private” badge, scope it to the recipient-side confidentiality, not to the entire sender history.

Compliance and disclosure

How to layer KYC, sanctions screening, and audit trails on top of Tachyon.