ZenoLOP
ZenoLOP is a limit-order protocol that operates across a RAILGUN shielded-pool boundary. A trader who wants to move value into the pool is matched with a counterparty already inside it who wants to move value out. Because the two legs offset, value crosses the boundary without either side paying the pool's entry and exit fees.
Every fill is bound to a zero-knowledge proof that the delivered note carries exactly the token, amount, and recipient key the order asked for, so a filler cannot substitute anything else.
Settlement runs in two phases. fillOrder delivers the shielded note and earmarks the matching
escrow in a single transaction; the filler then calls claimPayout within a claim window to release
it. If that window passes unclaimed, the maker reclaims the escrow.
The two sides
| Role | Position | Provides | Receives |
|---|---|---|---|
| Maker (entering the pool) | outside | public ERC20 escrow (takingToken) | a shielded note (makingToken) spendable by their pool key |
| Filler (exiting the pool) | inside | a shielded note delivered to the maker | the maker's escrowed public tokens, minus the taker fee |
The maker sets the price by choosing how much they escrow against how much they want delivered. Orders support partial fills: multiple fillers can each deliver part of the requested note amount and take a pro-rata share of the escrow.
How it is put together
- Contract -
ZenoLOP.sol, a RAILGUN adapt contract. It wrapsRailgunSmartWallet.transact(), holds the order book and the escrow, and binds each payout to the shielded proof. - Note-requirements circuit - a Noir circuit proving the delivered note carries the right token, value, and recipient key, verified on-chain by an UltraHonk verifier.
- Subgraph - indexes orders and payouts into a queryable order book.
Start here
- How ZenoLOP works - the order lifecycle and the fee-avoidance model.
- Binding and proofs - what makes a fill safe from front-running.
- Quickstart - build, test, and deploy.
- Integrating - drive the protocol from a wallet or filler bot.
- Contract reference - functions, events, and deployments.
- Subgraph reference - the indexed order book and the queries fillers use.