Private execution on BNB Chain, driven by intent.

01Introduction

Public blockchains are transparent by default. Every swap, transfer and balance is a permanent, searchable record tied to a wallet address. Once that address is linked to a person, their full financial history is exposed: positions, counterparties, timing and net worth.

That transparency is valuable for verification and expensive for the people being verified. Traders are copied and front-run. Treasuries leak strategy. Ordinary users reveal their entire balance to anyone they pay.

Privacy tooling exists, but adoption is held back by complexity. Users are expected to understand notes, relayers, anonymity sets and proof generation before they can move funds. Alibi removes that friction. The cryptography runs in the background, and the interface is a conversation.

02Design principles

Five constraints shaped every decision in the protocol.

Non-custodial by construction

Funds sit in a non-upgradeable smart contract and move only with a valid proof generated from the user's own keys. No operator, including the team, can move or freeze deposited funds.

Client-side proving

Zero-knowledge proofs are generated in the user's browser. Private keys and note secrets never leave the device.

Intent first

Users describe outcomes, not transactions. Routing, quoting and proof construction are handled for them.

Human in the loop

The AI proposes and the user approves. Nothing executes without an explicit confirmation that shows the real numbers.

Self-funding

Protocol revenue pays for the compute the product consumes.

03Architecture

Alibi is split across three trust domains. Anything sensitive stays with the user, anything that must be verifiable lives on-chain, and the services in between are built so they cannot alter a transaction.

Shielded pool

A single contract holds all deposited assets. Balances are represented as notes: cryptographic commitments to an amount, an asset and an owner key. The contract stores only these commitments, arranged in a Merkle tree, together with a set of nullifiers that mark notes as spent. It never learns who owns which note.

Proving system

Every transaction carries a Groth16 proof over a join-split circuit with two inputs and two outputs. The proof attests that the spender owns unspent notes in the tree, that value is conserved, and that the nullifiers are derived correctly, all without revealing which notes are being spent. Poseidon is used for hashing throughout.

Relayer

Transactions from inside the pool are submitted by a relayer, so the user's wallet never signs them on-chain or pays their gas. Every parameter is bound into the proof: recipient, amount, fee, swap route, minimum output and deadline. A relayer can submit a transaction or drop it, and cannot change it. The relayer is a convenience and not a gatekeeper, because the contract accepts a valid proof from any sender.

Liquidity

Swaps route through PancakeSwap directly from the pool contract, and the output returns to the pool as a new note. Funds never leave the shielded set during a swap.

04Transaction lifecycle

A typical session has three stages. Only the first one touches the user's public wallet.

1. Deposit

   The user sends BNB, USDT or USDC from their wallet to the pool and receives a private note of equal value.

   On-chain record

   This address deposited this amount.

   Stays hidden

   Everything that happens to the funds afterwards.

2. Private swap

   The browser builds a proof that spends the user's notes. The relayer submits it, the pool executes the swap on PancakeSwap, and the output is credited back to the same private account as a new note.

   On-chain record

   The pool swapped one asset for another.

   Stays hidden

   Whose funds were swapped, and which deposit they came from.

3. Private send

   A proof authorises a payout to any address. The relayer submits it and the recipient is paid by the pool contract, not by the user's wallet.

   On-chain record

   The pool paid this address this amount.

   Stays hidden

   Who authorised the payment.

05The intent layer

Alibi replaces the swap form with a sentence. A message such as "swap 0.05 BNB to USDT" is parsed by a large language model into a constrained, structured action: deposit, swap, send or balance.

The model's output is treated as untrusted input. It is validated against a strict schema, any address is checked against what the user actually typed, and the action is priced with a live quote before anything is shown. The user then sees a confirmation card with the real numbers and approves it. Only after that approval does the browser construct a proof.

The model holds no keys, has no signing authority and cannot move funds. It is stateless, and conversations are not retained. If the model is unavailable, a deterministic parser handles the same commands, so the protocol never depends on a single AI provider to function.

06Privacy model

Alibi provides unlinkability. It breaks the on-chain connection between the wallet that funded a position and everything that position does afterwards. It is important to be precise about what that covers.

Privacy is a function of the anonymity set. The more users and volume the pool carries, the harder it becomes to correlate activity. Users strengthen their own privacy by leaving time between a deposit and a send, and by avoiding payouts that mirror the deposit amount exactly.

07Protocol economics

Alibi is designed as a closed loop in which usage pays for intelligence.

1. Private swaps
2. Protocol fee
3. Compute treasury
4. AI inference

Protocol fee

A fee of 0.3% is taken on private swaps and routed to an on-chain compute treasury. The treasury funds the AI inference that powers the interface. The fee is a contract parameter and is hard-capped at 1% in code. Deposits and sends carry no protocol fee.

Network fee

Swaps and sends include a small network fee that reimburses the relayer for gas. It is paid in the asset being moved, so users never need to hold BNB in a fresh wallet to act privately.

Transparency

The treasury is a public address. Its balance is displayed inside the app and can be verified by anyone on-chain.

08$ALIBI

$ALIBI is the token of the Alibi ecosystem. It launches on Flap on BNB Chain and represents the product described in this paper: a live protocol with deployed contracts and working infrastructure.

Network

BNB Chain

Launch venue

Flap

Contract

Goes live at launch

09Security and trust

Proof-gated funds

Assets leave the pool only with a valid proof. Nullifiers make every note spendable exactly once, and value conservation is enforced inside the circuit.

Limited administration

The owner can pause new deposits, adjust the swap fee within its cap, update the list of supported assets and repoint the treasury. The owner cannot withdraw, freeze or redirect user funds.

No upgrade path

The pool is not a proxy and has no upgrade mechanism. The rules that were deployed are the rules that apply.

Exit guarantee

Sends out of the pool stay available when deposits are paused and when the pool reaches capacity.

Deterministic accounts

A private account is derived from a single wallet signature. The same wallet restores the same account on any device, and nothing is stored on a server. The signing request is bound to the official domain so wallets can flag imitations.

Encrypted notes

Note data is encrypted with AES-GCM before it is published, and only the owner's keys can read it.

10Specifications

Network

BNB Chain (chain ID 56)

Proof system

Groth16 on BN254

Circuit

Join-split, 2 inputs and 2 outputs, about 28,500 constraints

Hash function

Poseidon

Commitment tree

Merkle tree, depth 20

Capacity

1,048,576 notes, about 524,000 transactions

Supported assets

BNB, USDT, USDC

Liquidity source

PancakeSwap V2

Protocol fee

0.3% on swaps, capped at 1%

Slippage tolerance

1% by default

Gas per private transaction

About 1.5 to 1.7 million