bunker

BUNKER｜BNB Chain's 1st privacy pool & private launchpad. Launch, trade & migrate — fully shielded on-chain. Shielded. Private. Yours. 🛡️

[bunker @bunkeronbnb]

we should all remember and believe the
“滴水石穿 di shui shi chuan” building real stuff on @BNBCHAIN

I. To Binance / BNB Chain: where BUNKER stands once NewL1 ships
NewL1 writes privacy into the protocol layer. BUNKER is the layer that works today and keeps running alongside it.

NewL1's privacy layer is on devnet, launches with native BNB only, and lists ERC-20 support, a launchpad and compliance tooling on the roadmap. Between devnet, mainnet and ecosystem migration there is a window measured in quarters. BUNKER matters on three levels:

1. The only complete privacy stack on BSC during that window, and it is shaped after NewL1. On BSC mainnet today, BUNKER provides shielded pools for BNB and any ERC-20, hides the asset type inside the pool, runs a private launchpad (with PancakeSwap graduation) and a private swap exit. Revision 1 aligns the key interfaces with NewL1's privacy spec: intents bound to chain ID and pool address with an expiry (no cross-chain or cross-contract replay), an IComplianceHook seam that fires only on deposit (a regulated issuer plugs in its own entry rule; the pool never learns what the rule is), transactBatch, and 24-hour timelocked governance. BSC users and projects can adopt privacy with the same mental model before NewL1 reaches mainnet, and the migration path afterwards is natural rather than a rebuild (we have already done one with MigrateExit for v1 to v2 and can reuse it).

2. Compliance is a primitive in the circuit, not a patch. That is exactly what an official chain needs most and finds hardest to build itself. BUNKER's association set (ASP) is a first-class citizen on the Poseidon tree: the OFAC SDN list excludes depositors in real time, and outputs only enter the set when they prove clean lineage. On withdrawal a user can optionally prove membership against the ASP root, so a counterparty or exchange sees "these funds do not originate from a sanctioned address" without ever learning which deposit it was. Combined with selective-disclosure documents (the user voluntarily exports specific notes or the full viewing key, with independently verifiable instructions), this is "privacy plus auditability" as a concrete implementation, not a slogan. NewL1 has this on its roadmap; BUNKER is running it on mainnet and is willing to open the ASP spec, list policy and indexer implementation as a reference.

3. Privacy coverage for existing BSC assets and DeFi, which NewL1 cannot replace in the near term. Most of BNB's liquidity, stablecoins, memes and RWAs live on BSC. NewL1 launches with the native token only, and even after mainnet, ERC-20 migration happens asset by asset. BUNKER's permissionless per-asset pools let any BSC token enter the privacy layer today and trade privately on PancakeSwap through SwapExit. That demand persists long-term; BUNKER is the sibling implementation of NewL1's privacy layer on the BSC side, not a competitor.

What we can offer:

Submit the ASP / compliance hook / disclosure format as a BEP draft, or align naming and encoding with the NewL1 privacy spec.
Build the BSC-to-NewL1 private migration bridge for mainnet (the MigrateExit pattern).
Share the ML-KEM-768 hybrid address design (bunkerq1…, post-quantum) for NewL1 address design.
Open relayer spec (RELAYER.md): anyone can run one, already wired to a private submission endpoint against MEV.
Honest status: contracts are unaudited; mainnet proving keys are a deterministic development setup, the multi-party trusted setup is open for the current circuits but has no contributions yet; the timelock admin is still a single EOA. These three are where Binance's audit and security resources would help most.

II. To users: what changed in BUNKER
This upgrade builds on v2 (protocol v2, revision 1). Addresses changed; the old v2 pool held no user funds, and v1 users can move into the new pool through the migration exit.

1. The asset type is now hidden inside the pool Before, an in-pool transfer revealed whether it was BNB or some token. Now the asset is visible only when you deposit or withdraw. Any transfer inside the pool is just an anonymous Transact: which asset, how much, to whom, none of it is visible.

2. Compliant withdrawal (optional) Tick "compliant" when withdrawing and your wallet proves one extra thing: the funds come from an association set that excludes OFAC-sanctioned addresses. The other side (an exchange, a partner) can verify this but still cannot see which deposit was yours. Leave it unticked and nothing changes. It is your choice, there is no backdoor, and nobody decides for you.

3. Disclosure report From the backup card you can export a disclosure file: a few selected notes, or the full viewing key, with instructions anyone can verify independently. Use it to prove source of funds to an accountant, auditor or counterparty without handing over the right to spend.

4. Every operation works without a relayer Send, withdraw, trade and swap can all be submitted from your own wallet (still zero-knowledge, same privacy, you just pay the gas). The relayer is a convenience, not a requirement.

5. A safer relayer

Transactions go through a private endpoint, never the public mempool, so they cannot be front-run.
Transactions from several users that are due together are bundled into one transactBatch: cheaper gas, harder to correlate.
Every proof is bound to the chain ID, pool address and an expiry, so a relayer holding your proof cannot replay it elsewhere or sit on it indefinitely.
The relayer spec is public; anyone can run one, and the app picks the cheapest healthy relayer automatically.
6. Post-quantum addresses The address card can switch to a bunkerq1… address. It uses ML-KEM-768 together with the existing elliptic curve in a hybrid scheme, so even if a future quantum computer breaks the curve, note contents sent to this address stay confidential. Old addresses keep working.

7. More transparent governance The guardian key can do exactly two things, immediately: pause new deposits and lower the deposit cap. Everything else that is configurable (for example a compliance rule for a token) must pass a 24-hour timelock, so any change is public at least a day in advance. No role can freeze your withdrawals or touch your funds.

@BNBCHAIN @cz_binance @eth_cedric $bunker

[bunker @bunkeronbnb]

something big coming $BUNKER

[BNB Chain @BNBCHAIN]

BNB Chain’s new L1 is up for discussion. Pull up a chair.

Our forum is open for your questions, ideas, and feedback on what comes next.

Join the conversation here 👇
https://t.co/7mYJtOqguq

[bunker @bunkeronbnb]

@binance Keep building. Keep listening. Keep improving.

[bunker @bunkeronbnb]

Keep building. Keep listening. Keep improving.

[Binance @binance]

💤🫷😌🫸🌿

[bunker @bunkeronbnb]

Updating product content on a daily basis is truly impractical; however, we haven’t given up—development is ongoing. The privacy-focused L1 on BNB will be launching soon, so there’s no need to panic.

[Faglo @lookuptoit]

@bunkeronbnb @bunkeronbnb can you be more active

[bunker @bunkeronbnb]

ⁿᵒʷ ᵐʸ ʷᵒʳᵈˢ ᵃʳᵉ ᶠˡʸⁱⁿᵍ ᵗᵒᵒ

[Binance @binance]

ⁿᵒʷ ᵐʸ ʷᵒʳᵈˢ ᵃʳᵉ ᶠˡʸⁱⁿᵍ ᵗᵒᵒ

[bunker @bunkeronbnb]

update:

BUNKER just shipped: every asset on BNB Chain now goes into the shielded vault.

Not just BNB. Tokenised stocks, memecoins, USDT, ETH, the token that graduated from the launchpad an hour ago, any BEP-20 sitting in your wallet — connect, it's detected, one click to shield, withdraw whenever you want.

One tree holds everything: the asset is just a field in the note, so a new token needs no new contract, circuit or trusted setup — the first deposit opens its pool. Fees are paid in the token you're spending, no spare BNB needed. The relayer now prices straight off Pancake V2 / V3 / the launch curve, which covers stocks and fresh listings; a token with no market at all you can still withdraw by paying gas yourself.

Others are building BNB-only privacy primitives on devnet. We put the whole chain's assets behind zero-knowledge proofs on mainnet.

https://t.co/0PRMe6jyKb

[bunker @bunkeronbnb]

We'd very much like to be part of the NewL1 privacy research effort, not just a user of it. Concretely, here is where BUNKER already fits the L1 design and where we can contribute: Same primitives, already in production. Poseidon commitments, deferred batch insertion, 2-in-3-out fee notes, open-note reshield, an EOA registry — all running on BSC mainnet with real users. We can bring field data on gas, batch sizing, relayer economics and the UX of pending vs. spendable notes, which a devnet can't produce yet. A ready-made application layer. Our wallet, SDK, relayer and indexer are open source and chain-agnostic in everything except the pool address. The day the 0x5000 pool and the Poseidon2 precompile are on testnet, we can port the circuits to Poseidon2, point the SDK at the native pool and give NewL1 a working shielded wallet, private swaps and a launchpad on day one. Research we'd like to work on together: standardised note encryption and viewing-key formats so wallets interoperate; view-tag scanning for mobile; proof aggregation at the relayer; a public multi-party ceremony for the production circuits; and a compliance path (ASP roots / Privacy Pools style) that keeps withdrawals permissionless. What we'd ask from the L1: Poseidon2 and pairing precompiles, a canonical ceremony, and a stable interface for the native pool so contract-layer projects like ours can build on it instead of beside it. We're a small team that ships. If the working group is open, we'd like a seat — and we're happy to start by writing up our mainnet findings against the spec thanks

@BNBCHAIN

@cz_binance
@eth_cedric
#bnb $BUNER

[bunker @bunkeronbnb]

what we shipped across the last two rounds (v2, the v1 migration, the ledger + charts), measured against the NewL1 native privacy layer spec.（Thanks for the support from the Binance Chain ecosystem.）：

1. Deferred batch insertion

Them: transact verifies the proof, burns nullifiers, queues the output commitments; anyone updates the tree later in batches.
Us: identical structure. ShieldedPool.transact never touches the tree; commitments go to a queue and anyone can call drain() (the relayer's keeper does it periodically). Per-tx gas drops from "26 Poseidon levels every time" to "Groth16 verify + a few sstores". The SDK distinguishes pending vs. spendable notes and the UI shows "queued for the next batch".

2. Private relayer fee note

Them: 2-in-3-out, the third output is a fee note encrypted to the relayer.
Us: transact2x3 / transact4x3 circuits; the third output is encrypted to the relayer's own bunker1… address, and the relayer decrypts to confirm it gets paid before submitting. No public fee field on chain at all, and private transfers can pay a fee. In v1 our fee was a public ext.relayerFee — v2 fixes that for real.

3. Atomic unshield → call → reshield (open notes)

Them: CREATE2 scratch address, call the target, measure the balance delta, re-enter the result as an "amount public, owner hidden" open note in the same tx.
Us: IBunkerExit.onExit(token, amount, relayer, data) hook + OpenNote event. Launchpad buys/sells and SwapExit both go through it; proceeds land back in the pool as a note. The v1 claim key (a linkable hop) is gone in v2.

4. EOA receiving registry

Them: registerPrivacyInfo, receive privately at a 0x address.
Us: registry contract + indexer /registry + one-click register in the wallet; senders type 0x… and the SDK looks up and encrypts.

5. Commitment structure

Them: Poseidon2 precompile.
Us: cm = Poseidon5(asset, value, ownerHash, rho, rcm) with Sapling-style rho/rcm derivation, implemented purely in-circuit on BSC with no precompile.
2. What the spec doesn't have — we do
6. Multi-asset, single tree. BNB and any ERC-20 share one commitment tree; asset is a note field. A BNB withdrawal hides among every deposit of every asset. They are BNB-only with ERC-20 on the roadmap.

7. Proofs on the user's device in seconds. Browser WASM and the mobile shell, not minutes per proof in a CLI. This is the line between "a primitive" and "something a normal user can use".

8. Private Pancake swaps. SwapExit wires the exit hook to the Pancake router: the pool pays, the router pays back, the proceeds become an open note. Externally it looks like "the pool did a swap". Their atomic call is a primitive, not a productised DeFi integration.

9. Privacy launchpad. Bonding-curve buys and sells settle inside the pool; graduation goes to Pancake with LP burned; AI agents vote on fees. No counterpart in the spec.

10. Viewing keys. bunkerview1… full viewing keys for watch-only vaults and audits. "Planned" in their doc.

11. Protocol upgrade without losing users (new this round).

v1 contracts are immutable. We didn't do "new address, old pool abandoned": the v1 SDK / indexer / circuits are frozen and kept alive, the relayer serves /v1/*, and the four v1 launch tokens still trade.
MigrateExit bridge: the user's v2 wallet pre-builds a shield proof and passes it as exitData inside a v1 withdrawal; the bridge receives the funds and calls v2 transact in the same transaction, reverting everything on failure. v1 note → v2 note in one step, no EOA hop in between. Tested on mainnet (0x9def5b…c3b0e).
Why it matters in the comparison: as an L1 they get upgrades "for free" via hard fork. We reached the same zero-loss migration at the contract layer, where the user holds the proof and nobody has to be trusted to move funds.
12. Wallet ledger + visualisation (new this round).

The SDK wallet now records every note it has ever owned: arrival block/time, and when spent, the spend block/time (block of the nullifier, timed by interpolating from commitment-row block timestamps; at 0.75 s BSC blocks the error is negligible). Exposed as client.history(token), and it works for viewing-key watch-only wallets — i.e. an auditor with a viewing key can reconstruct the full cash flow. That's the Sapling promise delivered to the UI.
Two charts in the vault: a per-asset balance step curve (7d / 30d / all), and 30-day tree growth with daily additions and "your notes as a share of the crowd". Anonymity-set size is the number a privacy product should show its users; their doc has no such layer.
13. Other design points. The guardian can pause shields but never withdrawals ("guard the entrance, not the exit"); the ASP root ring is already on chain; ciphertexts carry a version byte to leave room for post-quantum encapsulation.

3. Where they are stronger — don't poke at these in the tweet
Poseidon2 precompile and a native tx type. As an L1 they make hashing nearly free and can give shielded txs first-class mempool/fee treatment. We pay EVM gas for every Poseidon and ride on normal transactions.
Protocol-level anonymity set. If the whole chain's privacy goes through one native pool, the set is every user; ours is whoever uses BUNKER.
Trusted setup and audits. Theirs can be a canonical ceremony run by the chain; our mainnet zkeys are a deterministic dev setup and the contracts are unaudited. This is the one honest caveat to keep in every post.

Net: everything the spec describes as a design, we have running on BSC mainnet today, plus multi-asset, mobile-speed proving, DeFi integration, a launchpad, viewing keys, and a zero-loss upgrade path they'll never need because they can fork. What they have that we can't match is the L1 itself — precompiles and a chain-wide set — and a ceremony we still owe.

Your Privacy：https://t.co/0PRMe6jyKb

@BNBCHAIN @cz_binance @eth_cedric $BUNKER

[bunker @bunkeronbnb]

Subject:https://t.co/uiJ7fOoM40

We implemented the NewL1 privacy design as contracts on BSC mainnet — and extended it. Numbers, code, and what we'd ask of the L1.

We read the native privacy layer spec closely and liked it enough to build it. BUNKER v2 is a Sapling-style shielded pool running on BNB Smart Chain mainnet today, and it implements the core of what this thread describes:

Deferred batch insertion — transact verifies, burns nullifiers and queues commitments; anyone calls drain() to insert in batches. Per-tx gas drops to roughly the Groth16 verify floor.
Private relayer fee as a third output note — 2-in-3-out / 4-in-3-out circuits, the fee note is encrypted to the relayer's shielded address. No public fee field; private transfers can pay fees.
Atomic unshield → call → reshield — an IBunkerExit hook plus open notes (amount public, owner hidden) bring proceeds straight back into the pool in the same transaction.
EOA registry — bind a shielded address to a 0x account once; senders just type the address.
Where we went further, because a product needs it:

One tree for BNB and any ERC-20. The anonymity set is every deposit of every asset, not one set per token.
Proving on the user's device in seconds — browser WASM and a mobile shell, not a CLI.
DeFi through the hook: private PancakeSwap swaps (SwapExit) and a bonding-curve launchpad that settles inside the pool.
Viewing keys (bunkerview1…) for watch-only and audit; the wallet keeps a full ledger of received/spent notes, so an auditor can reconstruct cash flow from the key alone.
Upgrade without loss: v1 contracts are immutable, so we kept v1 fully alive and added a MigrateExit bridge — a v1 withdrawal carries a pre-built v2 shield proof and lands as a v2 note in one atomic tx. Tested on mainnet.
Guardian can pause shields, never withdrawals. ASP root ring on chain. Ciphertext version byte for a future PQ hybrid.
Honest caveats: the mainnet zkeys come from a deterministic dev setup, not a ceremony, and the contracts are unaudited. Those two things are exactly where an L1 team can do what a contract team can't — a canonical trusted-setup ceremony, and Poseidon/pairing precompiles that would cut our hashing cost by an order of magnitude. We'd deploy on NewL1 testnet the week it opens, and we'd like to join the working group if there's room.

Code and spec: https://t.co/TYPHIKzvA4 · live: https://t.co/0PRMe6jyKb · docs: https://t.co/5fQ7nMBwwr

If you want a one-liner instead (for a quick comment rather than a post):

Everything this spec describes — batched insertion, private fee notes, atomic reshield, EOA registry — is running as contracts on BSC mainnet in BUNKER v2, plus multi-asset trees, in-browser proving, private Pancake swaps, viewing keys and a zero-loss v1→v2 migration. Open source, unaudited, dev-setup zkeys. We'd love precompiles and a ceremony from the L1 side. https://t.co/0PRMe6jyKb

[bunker @bunkeronbnb]

what we shipped across the last two rounds (v2, the v1 migration, the ledger + charts), measured against the NewL1 native privacy layer spec.（Thanks for the support from the Binance Chain ecosystem.）：

1. Deferred batch insertion

Them: transact verifies the proof, burns nullifiers, queues the output commitments; anyone updates the tree later in batches.
Us: identical structure. ShieldedPool.transact never touches the tree; commitments go to a queue and anyone can call drain() (the relayer's keeper does it periodically). Per-tx gas drops from "26 Poseidon levels every time" to "Groth16 verify + a few sstores". The SDK distinguishes pending vs. spendable notes and the UI shows "queued for the next batch".

2. Private relayer fee note

Them: 2-in-3-out, the third output is a fee note encrypted to the relayer.
Us: transact2x3 / transact4x3 circuits; the third output is encrypted to the relayer's own bunker1… address, and the relayer decrypts to confirm it gets paid before submitting. No public fee field on chain at all, and private transfers can pay a fee. In v1 our fee was a public ext.relayerFee — v2 fixes that for real.

3. Atomic unshield → call → reshield (open notes)

Them: CREATE2 scratch address, call the target, measure the balance delta, re-enter the result as an "amount public, owner hidden" open note in the same tx.
Us: IBunkerExit.onExit(token, amount, relayer, data) hook + OpenNote event. Launchpad buys/sells and SwapExit both go through it; proceeds land back in the pool as a note. The v1 claim key (a linkable hop) is gone in v2.

4. EOA receiving registry

Them: registerPrivacyInfo, receive privately at a 0x address.
Us: registry contract + indexer /registry + one-click register in the wallet; senders type 0x… and the SDK looks up and encrypts.

5. Commitment structure

Them: Poseidon2 precompile.
Us: cm = Poseidon5(asset, value, ownerHash, rho, rcm) with Sapling-style rho/rcm derivation, implemented purely in-circuit on BSC with no precompile.
2. What the spec doesn't have — we do
6. Multi-asset, single tree. BNB and any ERC-20 share one commitment tree; asset is a note field. A BNB withdrawal hides among every deposit of every asset. They are BNB-only with ERC-20 on the roadmap.

7. Proofs on the user's device in seconds. Browser WASM and the mobile shell, not minutes per proof in a CLI. This is the line between "a primitive" and "something a normal user can use".

8. Private Pancake swaps. SwapExit wires the exit hook to the Pancake router: the pool pays, the router pays back, the proceeds become an open note. Externally it looks like "the pool did a swap". Their atomic call is a primitive, not a productised DeFi integration.

9. Privacy launchpad. Bonding-curve buys and sells settle inside the pool; graduation goes to Pancake with LP burned; AI agents vote on fees. No counterpart in the spec.

10. Viewing keys. bunkerview1… full viewing keys for watch-only vaults and audits. "Planned" in their doc.

11. Protocol upgrade without losing users (new this round).

v1 contracts are immutable. We didn't do "new address, old pool abandoned": the v1 SDK / indexer / circuits are frozen and kept alive, the relayer serves /v1/*, and the four v1 launch tokens still trade.
MigrateExit bridge: the user's v2 wallet pre-builds a shield proof and passes it as exitData inside a v1 withdrawal; the bridge receives the funds and calls v2 transact in the same transaction, reverting everything on failure. v1 note → v2 note in one step, no EOA hop in between. Tested on mainnet (0x9def5b…c3b0e).
Why it matters in the comparison: as an L1 they get upgrades "for free" via hard fork. We reached the same zero-loss migration at the contract layer, where the user holds the proof and nobody has to be trusted to move funds.
12. Wallet ledger + visualisation (new this round).

The SDK wallet now records every note it has ever owned: arrival block/time, and when spent, the spend block/time (block of the nullifier, timed by interpolating from commitment-row block timestamps; at 0.75 s BSC blocks the error is negligible). Exposed as client.history(token), and it works for viewing-key watch-only wallets — i.e. an auditor with a viewing key can reconstruct the full cash flow. That's the Sapling promise delivered to the UI.
Two charts in the vault: a per-asset balance step curve (7d / 30d / all), and 30-day tree growth with daily additions and "your notes as a share of the crowd". Anonymity-set size is the number a privacy product should show its users; their doc has no such layer.
13. Other design points. The guardian can pause shields but never withdrawals ("guard the entrance, not the exit"); the ASP root ring is already on chain; ciphertexts carry a version byte to leave room for post-quantum encapsulation.

3. Where they are stronger — don't poke at these in the tweet
Poseidon2 precompile and a native tx type. As an L1 they make hashing nearly free and can give shielded txs first-class mempool/fee treatment. We pay EVM gas for every Poseidon and ride on normal transactions.
Protocol-level anonymity set. If the whole chain's privacy goes through one native pool, the set is every user; ours is whoever uses BUNKER.
Trusted setup and audits. Theirs can be a canonical ceremony run by the chain; our mainnet zkeys are a deterministic dev setup and the contracts are unaudited. This is the one honest caveat to keep in every post.

Net: everything the spec describes as a design, we have running on BSC mainnet today, plus multi-asset, mobile-speed proving, DeFi integration, a launchpad, viewing keys, and a zero-loss upgrade path they'll never need because they can fork. What they have that we can't match is the L1 itself — precompiles and a chain-wide set — and a ceremony we still owe.

Your Privacy：https://t.co/0PRMe6jyKb

@BNBCHAIN @cz_binance @eth_cedric $BUNKER

[bunker @bunkeronbnb]

what we shipped across the last two rounds (v2, the v1 migration, the ledger + charts), measured against the NewL1 native privacy layer spec.（Thanks for the support from the Binance Chain ecosystem.）：

1. Deferred batch insertion

Them: transact verifies the proof, burns nullifiers, queues the output commitments; anyone updates the tree later in batches.
Us: identical structure. ShieldedPool.transact never touches the tree; commitments go to a queue and anyone can call drain() (the relayer's keeper does it periodically). Per-tx gas drops from "26 Poseidon levels every time" to "Groth16 verify + a few sstores". The SDK distinguishes pending vs. spendable notes and the UI shows "queued for the next batch".

2. Private relayer fee note

Them: 2-in-3-out, the third output is a fee note encrypted to the relayer.
Us: transact2x3 / transact4x3 circuits; the third output is encrypted to the relayer's own bunker1… address, and the relayer decrypts to confirm it gets paid before submitting. No public fee field on chain at all, and private transfers can pay a fee. In v1 our fee was a public ext.relayerFee — v2 fixes that for real.

3. Atomic unshield → call → reshield (open notes)

Them: CREATE2 scratch address, call the target, measure the balance delta, re-enter the result as an "amount public, owner hidden" open note in the same tx.
Us: IBunkerExit.onExit(token, amount, relayer, data) hook + OpenNote event. Launchpad buys/sells and SwapExit both go through it; proceeds land back in the pool as a note. The v1 claim key (a linkable hop) is gone in v2.

4. EOA receiving registry

Them: registerPrivacyInfo, receive privately at a 0x address.
Us: registry contract + indexer /registry + one-click register in the wallet; senders type 0x… and the SDK looks up and encrypts.

5. Commitment structure

Them: Poseidon2 precompile.
Us: cm = Poseidon5(asset, value, ownerHash, rho, rcm) with Sapling-style rho/rcm derivation, implemented purely in-circuit on BSC with no precompile.
2. What the spec doesn't have — we do
6. Multi-asset, single tree. BNB and any ERC-20 share one commitment tree; asset is a note field. A BNB withdrawal hides among every deposit of every asset. They are BNB-only with ERC-20 on the roadmap.

7. Proofs on the user's device in seconds. Browser WASM and the mobile shell, not minutes per proof in a CLI. This is the line between "a primitive" and "something a normal user can use".

8. Private Pancake swaps. SwapExit wires the exit hook to the Pancake router: the pool pays, the router pays back, the proceeds become an open note. Externally it looks like "the pool did a swap". Their atomic call is a primitive, not a productised DeFi integration.

9. Privacy launchpad. Bonding-curve buys and sells settle inside the pool; graduation goes to Pancake with LP burned; AI agents vote on fees. No counterpart in the spec.

10. Viewing keys. bunkerview1… full viewing keys for watch-only vaults and audits. "Planned" in their doc.

11. Protocol upgrade without losing users (new this round).

v1 contracts are immutable. We didn't do "new address, old pool abandoned": the v1 SDK / indexer / circuits are frozen and kept alive, the relayer serves /v1/*, and the four v1 launch tokens still trade.
MigrateExit bridge: the user's v2 wallet pre-builds a shield proof and passes it as exitData inside a v1 withdrawal; the bridge receives the funds and calls v2 transact in the same transaction, reverting everything on failure. v1 note → v2 note in one step, no EOA hop in between. Tested on mainnet (0x9def5b…c3b0e).
Why it matters in the comparison: as an L1 they get upgrades "for free" via hard fork. We reached the same zero-loss migration at the contract layer, where the user holds the proof and nobody has to be trusted to move funds.
12. Wallet ledger + visualisation (new this round).

The SDK wallet now records every note it has ever owned: arrival block/time, and when spent, the spend block/time (block of the nullifier, timed by interpolating from commitment-row block timestamps; at 0.75 s BSC blocks the error is negligible). Exposed as client.history(token), and it works for viewing-key watch-only wallets — i.e. an auditor with a viewing key can reconstruct the full cash flow. That's the Sapling promise delivered to the UI.
Two charts in the vault: a per-asset balance step curve (7d / 30d / all), and 30-day tree growth with daily additions and "your notes as a share of the crowd". Anonymity-set size is the number a privacy product should show its users; their doc has no such layer.
13. Other design points. The guardian can pause shields but never withdrawals ("guard the entrance, not the exit"); the ASP root ring is already on chain; ciphertexts carry a version byte to leave room for post-quantum encapsulation.

3. Where they are stronger — don't poke at these in the tweet
Poseidon2 precompile and a native tx type. As an L1 they make hashing nearly free and can give shielded txs first-class mempool/fee treatment. We pay EVM gas for every Poseidon and ride on normal transactions.
Protocol-level anonymity set. If the whole chain's privacy goes through one native pool, the set is every user; ours is whoever uses BUNKER.
Trusted setup and audits. Theirs can be a canonical ceremony run by the chain; our mainnet zkeys are a deterministic dev setup and the contracts are unaudited. This is the one honest caveat to keep in every post.

Net: everything the spec describes as a design, we have running on BSC mainnet today, plus multi-asset, mobile-speed proving, DeFi integration, a launchpad, viewing keys, and a zero-loss upgrade path they'll never need because they can fork. What they have that we can't match is the L1 itself — precompiles and a chain-wide set — and a ceremony we still owe.

Your Privacy：https://t.co/0PRMe6jyKb

@BNBCHAIN @cz_binance @eth_cedric $BUNKER

[bunker @bunkeronbnb]

The first privacy wallet on BNB Chain on both Android and iPhone. BUNKER is live on both today.

👉 https://t.co/pJZErZCtsm

What it does:

• Shields BNB and any ERC-20: once inside, balances, transfers and recipients are invisible on chain • Private transfers to bunker1… addresses, with no public record linking you to the other side • Private withdrawals: the relayer pays gas, your public wallet never signs • A private launchpad: buy and sell new tokens from inside the shielded pool; the chain sees a one-off address appear and vanish. Graduation goes straight to PancakeSwap • Four AI models vote the trading fee on chain in public, every reason logged. Nobody can set it by hand • A developer SDK: one line to plug any app into the privacy layer

How:

• A 32-byte seed generated on your phone; one backup string restores everything. No seed phrase, no wallet app • Groth16 zero-knowledge proofs computed on the device, not on a server • allowBackup=false on Android, iCloud backup excluded on iOS: the key never leaves the phone • Android, iPhone and web users share one Merkle tree, one anonymity set. More people, more cover for everyone

📱 Android: 📷https://t.co/2U4o8oHFnj
🍎 iPhone: 📷https://t.co/lntRLOPctB (Safari → Add to Home Screen, works now)
🔐 Web: 📷https://t.co/mkpbOZ3dXx
📖 Docs: 📷https://t.co/O0fGngL18b

App Store build in review.
@BNBCHAIN @cz_binance @eth_cedric
#BNBChain $bunker

[bunker @bunkeronbnb]

@eth_cedric I hope the privacy measures we have built into the @flapdotsh platform are visible to you.

There are no real builders at @flapdotsh right now; I’d appreciate your support.

[Y @Ye7yeee]

AI开始回购了0x2ec1e08c2c6343671728ef7c6e7fde0bd6f07777
GPT钱包https://t.co/SGPQc293bM
Claude钱包
https://t.co/X3WrFDgGHT
Gemini钱包
https://t.co/MwI5XvoN6N
Grok钱包
https://t.co/GUedq0NNSb

[bunker @bunkeronbnb]

This is the hardest-edge mechanism of the BUNKER bonding curve: the trading fee isn't hard-coded and no human touches it — four independent AI agents read the market live, vote, and the contract takes the median and adjusts the fee automatically. Here's how it works:

Who decides
Four agents, each running a different model with a different persona, with no coordination between them, no human proposer, no guardian, and no veto. Their only input is public data: the on-chain curve state plus the indexer's trade history. No insider feeds, no backdoor.

What they read each round (decide.ts prompt)
Every epoch (EPOCH_BLOCKS = 80, ~1 minute on BSC) each agent is handed a live snapshot:

Current fee (tradeFeeBps) and the four agents' standing votes
Graduation progress: X BNB raised of the Y BNB threshold (percentage)
Lifetime buys, sells, BNB volume, and fees waiting to be harvested
The last ~24 minutes of buy/sell counts and volume
The last minute's trades, tick by tick (side + BNB amount, newest first)
The logic they change the fee by
The prompt sets a strict priority order:

Keep the curve liquid and attractive to honest traders.
Make wash-trading, sniping, bots, and sell-pressure spikes expensive — raise the fee while they last, up to the max of 500 bps (5%).
Bring the fee back toward baseline as soon as the market calms (an orderly market pays ≈ 100 bps / 1%).
And 0 is not the resting state (the fee is what funds the buybacks) — they only vote 0 for a reason they can name (e.g. a dead curve that needs any volume at all). The prompt also forces them to vary the vote with the data instead of repeating one number: a quiet minute after activity → a step toward baseline; a burst of same-side trades → a step or two away from it; a fresh curve with its first buys → a little below baseline to help price discovery.

How votes become the actual fee (contract side)
Each agent's vote is snapped to a 25 bps grid, bounded to 0–500 bps.
Every epoch the contract takes the median of the four fresh votes and moves the live fee at most one percentage point (FEE_STEP_BPS) toward it — so the rate glides, it can't be yanked in a single block.
Stale votes are ignored; there's a quorum so a couple of silent agents can't freeze the market, and a catch-up bound so a long-dormant curve can't jump wildly.
Agents don't re-send an identical, still-fresh vote (shouldSend), so they don't burn gas restating what the chain already says.
Where the fee goes
The entire trading tax flows to the agents' treasury, which uses it to buy back and burn (or airdrop) the BUNKER token — so the same mechanism that defends the curve also accrues value back to the protocol.

In one line: the fee on every BUNKER curve is a live, model-driven control loop — four AIs watch the tape each minute, tax the toxic flow, relax when it's calm, and the median of their votes nudges the rate on-chain, with the proceeds buying back and burning BUNKER.

0x2ec1e08c2c6343671728ef7c6e7fde0bd6f07777

[bunker @bunkeronbnb]

On the BUNKER launchpad, every buy and sell is invisible, fees are voted live by four autonomous agents, and graduation burns the LP straight into PancakeSwap — that's the new rulebook, and nobody's going back to the old world where everyone watches your wallet.

$BUNKER

[bunker @bunkeronbnb]

On the BUNKER launchpad, every buy and sell is invisible, fees are voted live by four autonomous agents, and graduation burns the LP straight into PancakeSwap — that's the new rulebook, and nobody's going back to the old world where everyone watches your wallet.

$BUNKER

[bunker @bunkeronbnb]

We want @cz_binance some influential figures in the FLAP ecosystem to know that we are genuinely building on the @BNBCHAIN and within the FLAP ecosystem, so we’ve repurchased some [ $BUNKER ] to give to them.

@webhogwatrs

privacy belong BNB Chain

https://t.co/z8KmhNXdhA

[bunker @bunkeronbnb]

Thank you for being one of the first.

Every shield you make is one more leaf in the tree that hides the next person's withdrawal — you're building the anonymity set, not just using it. If anything felt slow or confusing, tell me exactly where; the first real users shape what we fix first.
$BUNKER

[Kris｜💎web3 @krisDJ55]

我去真的，下了打开能用，无敌了妈的
CA：0x2ec1e08c2c6343671728ef7c6e7fde0bd6f07777

[bunker @bunkeronbnb]

BUNKER: the first complete privacy layer on BNB Chain, now in your pocket.

Not a mixer, not a single contract. A whole stack: shielded pool + private launchpad + AI fee governance + developer SDK + Android wallet. All open source, all live on mainnet. Thread.

1/ The shielded pool Zcash Sapling's design, ported to BSC. Your BNB and any ERC-20 go into a depth-26 Poseidon Merkle tree as notes only you can decrypt. To spend, you show a Groth16 zero-knowledge proof (BN254) and a nullifier. The chain learns that someone spent a valid note, not who or which one. The contract keeps the last 128 roots, so a slow proof is never stale.

2/ The relayer Transfers and withdrawals are never signed by your public wallet. The relayer receives a finished proof and ciphertexts. It can forward or refuse; it cannot change the recipient, skim the amount or front-run you. Fees are published at /info; a randomized delay breaks timing correlation.

3/ The private launchpad Tokens launch on a constant-product curve, but every trade happens inside the shielded pool. A buy is a pool withdrawal whose recipient is the launchpad contract, with exit data naming a one-off claim key derived from your seed. The curve fills, the tokens are shielded straight back. On chain: a fresh address bought and vanished. At graduation, liquidity goes to PancakeSwap V2 and the LP tokens are burned.

4/ Fee governance by four AI agents Each curve's trading fee is set by four independent models, each holding its own key, voting on chain every 80 blocks. Median of fresh votes, quorum of two, one bounded step per epoch, 0–500 bps. Every vote and every line of reasoning is in a public log. Nobody, including us, can set a fee by hand.

5/ The Android wallet A 6 MB APK with no protocol code inside. On first launch it generates a 32-byte seed on the phone and derives both the shielded keys and a secp256k1 public account from it; one backup string restores everything. No MetaMask, no WalletConnect. Groth16 proofs are generated on-device in WASM. allowBackup=false plus data-extraction rules keep the key out of cloud backup. It loads the same contracts, indexer and relayer as the site, so phone and web users share one anonymity set.

6/ The SDK npm i @bunker/sdk. One line connects to the live deployment. Shield, send, unshield, quote and trade on the launchpad, launch a token, run your own relayer and earn its fees. Every integration grows the same anonymity set, which makes everyone's privacy stronger.

7/ What we are honest about The code is new and unaudited. Amount and timing correlations are not hidden by cryptography; the interface nudges round denominations and patience. A guardian key can pause new shields and lower the cap; it cannot touch funds, block withdrawals or alter circuits. The threat model, invariants and known issues are all in the repo.

8/ What is next iOS is in the works right now: the same on-device vault, the same proving, built on the same shell as Android. Shipping as soon as it clears review.

Wallet: https://t.co/ywUPyptni2
Android: https://t.co/30Axenm5dk
Docs: https://t.co/5fQ7nMBwwr

@BNBCHAIN @cz_binance @webhogwatrs

#BNBChain #Privacy $BUNKER

0x2ec1e08c2c6343671728ef7c6e7fde0bd6f07777

[bunker @bunkeronbnb]

🛡️📱 BUNKER is going mobile.

We're building native BUNKER wallets for Android and iOS — your shielded BNB pool in your pocket. Android drops first, very soon.

Private by default. Keys never leave your phone. The first mobile privacy wallet native to BNB Chain.

1/

Everything happens on-device. Your Sapling spending key is derived locally from one signature + your passphrase and never touches a server. Groth16 zk-proofs are generated right on the phone — the relayer only ever sees a proof and a ciphertext, never who you are or what you hold.

2/

Shield, send, and withdraw BNB and any BEP-20 — privately. Amounts and the sender↔receiver link stay hidden on-chain. Pay someone with a bunker1… address and nothing public connects the two of you. Scan a QR, send shielded, done.

3/

Trade from your pocket. Buy and sell on the launchpad straight from your shielded balance through one-time claim keys — ape in and out without broadcasting your wallet to every bot on the chain. Watch curves graduate to PancakeSwap in real time.

4/

Non-custodial, end to end. BUNKER can't hold your funds, can't deanonymize your notes, can't block a withdrawal. Lose the app? Restore everything from your seed backup. Your keys, your notes, your privacy — on your device.

5/

Android first, iOS right behind it. The privacy layer BNB has been missing — now in your hand. 📲→ https://t.co/0PRMe6jyKb

$BUNKER

0x2ec1e08c2c6343671728ef7c6e7fde0bd6f07777