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. Ghostie 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 Ghostie 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.

Planned · not live

Interface API

The endpoints the app is designed to call once an execution service is connected. They cover the exchange lifecycle only; none of them generates Ghostie proofs. In demo mode the app calls none of them: js/catalog.js stands in.

• API keys stay on the server.
• Quotes are estimates.
• Creating an order is idempotent per request ID; a request that times out is never repeated automatically.
• The execution service validates the destination address before an order exists.
• Only verified deposit instructions are ever shown.
• The recovery link opens the order's details, so keep it private.

The Ghostie economy

100% service-fee cashback in SOL

After a completed swap you can ask for 100% of the actual service fee back, paid manually in native SOL. Network fees, gas, slippage and rate differences aren't included. Holding $GHOSTIE on its own doesn't earn cashback.

How to request cashback

1. Complete your exchange and keep its private recovery link.
2. On the success screen, enter the Solana address that should receive SOL. Check it twice: it can't be changed in the app afterwards.
3. The server confirms the exchange completed and saves one request per exchange. Submitting again doesn't add a second reward.
4. The operator verifies the actual service fee and works out its value in SOL. A quote's spread or an unverified estimate never counts as the final fee.
5. The operator sends SOL manually. Submitting is not payment: until the fee is verified, the request stays pending.

Fee verification and conversion

The refund is based on the actual service fee that wasn't refunded. For each payout the operator records the fee and its currency, the conversion rate with its source and time, the final amount in lamports and the payment transaction. Processing time isn't fixed. If the fee can't be verified, the request stays pending; a zero fee pays nothing.

cashback  = 100% of the verified service fee
payoutSOL = verified fee value / SOL price at review
one completed exchange → at most one cashback request

Private payout records

Requests are meant to live on the server, not only in your browser. Your Solana address is shared with the payout operator and linked to your exchange; the payout register isn't public. Anyone holding your recovery link can view or submit that exchange's request, so keep it private. Never enter a seed phrase or private key. Nothing is paid automatically.

In demo mode: cashback requests are saved only in your browser, and nothing is reviewed or paid.

$GHOSTIE buybacks

The plan is to put all platform revenue toward buying back $GHOSTIE. SOL cashback comes from a separate budget, so the same revenue is never counted twice. Swap principal and pass-through network fees aren't platform revenue. Buybacks aren't active: the token address, treasury, execution rules and reporting all have to exist first.

Engineering roadmap

1. InterfaceAvailable in demo mode.
2. Execution serviceConnect live quotes, order creation, deposit instructions and status.
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; Ghostie isn't affiliated with either project and doesn't inherit their security.