Zero-knowledge.
Across chains.

What exists today

Development status

Target architecture

Commit → prove → settle

1. 01Source chainDeposit or lock eventCommitment tree
2. 02Proving layerPrivate witnessPublic statement
3. 03DestinationAuthenticated source stateProof & replay checks

This is a reference design, not a description of something running. Before a bridge accepts value it has to define custody, supported chains, finality rules, fees and how assets exist on the destination.

1. Establish the source state

After an eligible deposit or lock, a source contract records a commitment. The commitment root only counts once the source chain has reached the required finality. How the destination verifier comes to trust that root is a separate security decision.

2. Construct the proof

The client builds a proof from its private note and the note's membership path in the commitment tree. The circuit enforces ownership and value rules. Whether proving happens in the browser or on a server, and how a lost witness is recovered, are implementation choices still to be made.

3. Authorize settlement on the destination

The destination checks the proof, its public inputs, the accepted source root and the spend marker. Only when all of them pass can the settlement mechanism release or issue value.

Notes & commitments

A note is your private record of a position in the protocol. A commitment is the public, cryptographic stand-in for that note. A sound construction binds every field the circuit uses, with unambiguous encoding, domain separation and enough secret randomness.

Illustrative only. Not a production circuit.
C = Commit(protocol_version, source_domain,
           asset_id, value, owner_secret, randomness)

Public record:      C
Private witness:    note fields + membership path
Still to be chosen: the commitment function and its encoding

A note is not your wallet's seed phrase. How notes are stored, backed up, encrypted and recovered needs its own design. Publishing a commitment proves nothing about a deposit on its own, and it doesn't hide a transparent deposit transaction.

What the proof must establish

"I know a valid, authorized note in an accepted source state, and this destination action follows the protocol's spending rules."

The final circuit has to constrain every field that affects authorization or value: range checks, conservation of value, fees, domain separation and binding to the recipient and action. A proof establishes only what the circuit actually encodes. It can't make up for a missing constraint.

Nullifiers and replay protection

A nullifier marks a note as spent without revealing the note's secrets. The protocol must stop a note being spent twice on any destination it can reach. Separate nullifier lists per chain aren't enough if the same note could be redeemed on two chains independently; notes need to be bound to one destination, or spends need one consistent authorization across chains.

Cross-chain settlement

A valid proof about a note doesn't prove the source chain has finalized. The bridge has to authenticate source state on its own and refuse stale, forged or reorganized roots.

State transport

How roots reach the destination: light-client proofs, consensus proofs, a messaging protocol or an attestation system.

Asset model

Lock and mint, burn and release, or liquidity-based settlement. Inkk hasn't chosen one yet.

Failure recovery

What happens when proving, transport or execution fails, including retries that can never settle twice.

Finality

Supported chains, confirmation rules, reorganization handling and the conditions that halt the bridge.

A relayer can carry messages and pay gas, but must never be able to change the recipient, amount or destination. If settlement relies on a signer set or an operator, that trust assumption has to be stated plainly.

Privacy model

The aim is to disclose as little as possible while keeping everything independently checkable. Any privacy claim has to name the observer it holds against and follow from the circuit and transaction flow that are actually deployed.

An external exchange service doesn't shield balances, doesn't produce Inkk proofs and doesn't hide transfers from itself. Private balances or selective disclosure would need extra mechanisms that are actually built. Routing through a privacy-focused asset doesn't by itself mean a shielded transfer happened.

Security & trust boundaries

• Circuit correctness. Constraints, public inputs and witness handling get an independent review.
• Verifier consistency. The deployed verifier is pinned to reviewed circuits and published parameters.
• Value safety. Conservation is proven, and double spends, cross-domain replays and recovery paths are tested.
• Operator powers. Upgrade keys, pause controls, signer roles and custody assumptions are published.
• User safety. Networks, recipient binding, fee limits and expiry are checked before any deposit is accepted.

Nothing here claims an audit, a trusted-setup ceremony, production proving performance or a mainnet deployment. Those claims need published artifacts behind them.

Live

Interface API

The endpoints the app calls on Inkk's own server, which checks each request and passes it to SWAP.MY. They cover the exchange lifecycle only; none of them generates Inkk proofs.

• The SWAP.MY API key stays on the server.
• Quotes are estimates; the final amount is set when your deposit is confirmed.
• Creating a swap is never retried automatically.
• SWAP.MY validates both addresses before a swap exists.
• The only deposit address ever shown is the one SWAP.MY returns for your swap.
• The swap reference (and the recovery link that holds it) opens the swap's details, so keep it private.

The Inkk economy

Where the fee goes

SWAP.MY charges a fee on each swap. It is shown in every quote and already included in the amount you receive, and Inkk adds nothing on top. As a SWAP.MY partner, Inkk receives a share of that fee for each completed swap.

$INKK buybacks

The plan is to put all of Inkk's revenue share toward buying back $INKK. Swap amounts and network fees are never revenue. Buybacks aren't active: the treasury, the execution rules and public reporting all have to exist first, and holding $INKK earns nothing on its own.

There is no cashback. An earlier version of this page described one; it was never switched on.

Engineering roadmap

1. InterfaceAvailable.
2. Execution serviceConnected: swaps are carried out by SWAP.MY.
3. Protocol specificationFinalize the proof statement, custody model, state authentication and cross-chain replay rules.
4. ImplementationBuild the bridge backend, circuits, verifier and recovery paths.
5. TestnetPublish contracts and artifacts; test finality, conservation of value and failed-settlement recovery.
6. Review & releaseIndependent security review, resolved findings, documented operator controls and explicit launch conditions.

No launch date is promised. This page changes as reviewable code and deployments exist.

Background & references

For a general introduction to zero-knowledge proofs, read Zcash: What are zk-SNARKs? For circuit concepts, see the Circom documentation. These explain the techniques; Inkk isn't affiliated with either project and doesn't inherit their security.