Privacy guarantees

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. It’s why we have an on-chain intent submission step today rather than pushing everything into the relayer. We’re moving to an off-chain intent model with an equivalent recovery guarantee; see the roadmap.
• 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)

​

Threat model

​

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.

​

What integrators should not claim to users

Be careful not to overstate the guarantees. If your product surfaces a “private” badge, scope it to the recipient-side confidentiality, not to the entire sender history.