From fec9f09731c542f7f3bb600a875cf105afcb5e74 Mon Sep 17 00:00:00 2001 From: alexand3rwilke Date: Fri, 4 Sep 2026 10:27:45 +0200 Subject: [PATCH 1/3] =?UTF-8?q?feat(vendor):=20add=20Bermuda=20=E2=80=94?= =?UTF-8?q?=20privacy=20and=20compliance=20layer=20for=20the=20EVM?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bermuda deploys as smart contracts on existing EVM chains: client-side Noir/Barretenberg proving, a KYT deposit gate with Proof-of-Innocence withdrawals and an on-chain Chainalysis sanctions oracle, per-token issuer policies (public or private) with issuer viewing keys and clawback, FROST multisig shielded accounts, Safe-authorized recovery, and coordinator-free cross-chain DvP over ERC-7888 broadcast proofs. Featured as the privacy example (Box 5) in the GL1 Programmable Compliance white paper (June 2026). Co-Authored-By: Claude Code --- vendors/bermuda.md | 147 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 vendors/bermuda.md diff --git a/vendors/bermuda.md b/vendors/bermuda.md new file mode 100644 index 0000000..a1e79bf --- /dev/null +++ b/vendors/bermuda.md @@ -0,0 +1,147 @@ +--- +title: "Vendor: Bermuda" +status: ready +website: https://bermudabay.xyz/ +category: privacy-layer +ethereum_aligned: true +last_reviewed: 2026-09-03 +maturity: testnet +--- + +# Bermuda – Privacy and compliance layer for the EVM + +## What it is + +Bermuda is a privacy and compliance layer deployed as contracts on existing +EVM chains. Funds sit in a smart contract as shielded UTXOs: balances, amounts and +counterparties are hidden by zero-knowledge proofs generated on the user's +device, and every transfer proves in zero knowledge that it satisfies the +issuer's policy for that token. Sanctions screening, retroactive flagging with +Proof of Innocence, issuer policies and clawback are enforced by the smart +contract and its circuits, not by an operator who reads transactions. It is +middleware, not a chain, wallet or custodian. + +## Fits with patterns + +- [Shielding](../patterns/pattern-shielding.md) +- [Proof of Innocence](../patterns/pattern-proof-of-innocence.md) +- [Compliance Monitoring](../patterns/pattern-compliance-monitoring.md) +- [Regulatory Disclosure Keys & Proofs](../patterns/pattern-regulatory-disclosure-keys-proofs.md) - issuer viewing keys +- [Private Stablecoin Shielded Payments](../patterns/pattern-private-stablecoin-shielded-payments.md) +- [Stealth Addresses](../patterns/pattern-stealth-addresses.md) +- [Private Transaction Broadcasting](../patterns/pattern-private-transaction-broadcasting.md) +- [Immutable Guarantees](../patterns/pattern-immutable-guarantees.md) +- [Social Recovery](../patterns/pattern-social-recovery.md) +- [DvP (ERC-7573)](../patterns/pattern-dvp-erc7573.md) - partial fit: cross-chain DvP via ERC-7888 proofs + +## Not a substitute for + +- Not a privacy L2 or separate ledger: everything runs on the host chain; no + sequencer, coprocessor network or bridge in the transaction path +- Not a wallet or custodian: users keep their keys in existing wallets + +## Architecture + +- **Smart contract**: holds funds as shielded UTXOs: commitments in + an incremental Merkle tree, chain-bound nullifiers, one `transact` entry point. + Notes are encrypted to the recipient's x25519 key and emitted as events. +- **Proofs and keys**: Noir circuits, Barretenberg as ZK proving backend, + client-side proving in WASM. Spend authorization is Schnorr over Grumpkin; FROST + threshold Schnorr puts a Safe's owners behind a shielded account. +- **Issuer policy engine**: the token owner (typically a Safe) sets a + per-token policy — spending limit per period, allow and deny lists, an + optional issuer viewing key — that every transfer proves in-circuit against + the smart contract's live policy root. The circuit checks a commitment to the policy's + fields, so an issuer can publish its rules or keep them private; list + membership stays off-chain either way. The viewing key yields an encrypted + view of that token's transfers; the issuer can claw back funds with a proof. +- **Compliance Gateway**: deposits bind the compliance engine's key and an + expiry block into the proof, so a delisted address cannot replay an + approval. Flagged deposit ids live in an indexed Merkle tree: private + withdrawals prove exclusion, disclosed ones inclusion. Depositors and + recipients are also screened on-chain by the Chainalysis sanctions oracle. +- **Roles**: the smart contract and verifiers are non-upgradeable. A governor + sets fees, + recovery parameters and the public-withdrawal delay and assigns a pauser, + who halts `transact` and `claim` for incident response. +- **Cross-chain DvP**: two smart contracts act as escrows: a leg is locked, + released + once the counterparty's lock is proven present, or reclaimed on a proof of + absence after the cutoff — ERC-7888 broadcast proofs, no coordinator. Linea + proof of concept, June 2026. +- **Products**: + - SDK suite: `core-sdk`, `issuer-sdk`, `safe-sdk`, `fireblocks-sdk`, etc. + - E2E apps: Private Safe Wallet, universal/mobile app in progress +- **Services**: + - E2E enterprise applications, from development through operations to compliance, for instance: + - Exclusive OTC/DvP/RFQ networks (always private, cross-chain capable) + - Customized private wallet UX, especially enterprise- and institution-focused + - Accounting/reporting and compliance adapters, and middleware + - MPC overlay upgrades on top of institutions’ physical HSMs through the partnership with Utila + +## Privacy domains + +- Balances, amounts and the transaction graph are hidden. Stealth addresses + keep public 3rd party protocol interactions unlinkable. +- Two exits: private (exclusion proof, deposit not revealed) and disclosed (if flagged by the compliance engine). +- Disclosure is scoped: an issuer viewing key decrypts transfers of that + issuer's token and nothing else; the compliance engine sees the depositor's + public address and never activity inside the contracts. + +## Enterprise demand and use cases + +- **Stablecoin, deposit-token and RWA issuers**: private or public policies, + issuer viewing key and clawback give the issuer the controls expected of a + regulated token while holders keep confidential balances +- **Regulated tokenised assets**: the privacy example (Box 5) in the Global + Layer One white paper *Programmable Compliance* (June 2026, with Banque de + France, the IMF, Kinexys by J.P. Morgan, MAS and Standard Chartered) +- **Banks and institutions**: shielded treasury under Safe multisig, + recoverable accounts, atomic cross-chain DvP and PvP, bilateral repo and OTC + swaps +- **Wallets and neobanks**: shielded balances and transfers behind existing UX +- **Payments**: payroll, card settlement, x402 +- **Asset management**: shielded ERC-4626 positions, private yield and DeFi, + private order books + +## Technical details + +- Curves in use: BN254 (proof system), Grumpkin (signatures), Curve25519 (encryption) +- Proof system: Noir, Barretenberg (UltraHonk); no circuit-specific trusted setup (universal SRS) +- Signing: Schnorr, FROST, Golden DKG +- Encryption: XChaCha20-Poly1305 + +Post-quantum implementation in progress. + +## Strengths + +- Issuer self-onboarding: any token owner can attach and update a policy + without Bermuda's involvement +- Signer-agnostic: multisig, passkey and MPC signers, plus account recovery +- Compliance is proved, not observed: screening, flagging, sanctions, issuer + policy and Proof of Innocence are verified by contract and circuit +- Issuer powers are strong by design: an issuer keeps the abilities it has on + the public chain, selective freezing and clawback included, in the shielded domain too +- Trust model is the host chain plus standard zk-SNARK assumptions: no Trusted + Execution Environment, multi-party computation committee or coprocessor + network in the confidentiality path +- No new ledger: same chain, same tokens, same wallets +- Exit is protocol-level: withdrawal is always available, private for clean + and disclosed for flagged lineage; the operator cannot freeze an account + +## Risks and open questions + +- Testnet stage: no mainnet deployment, third-party audit or bug bounty published +- Anonymity depends on activity in the contracts per chain and asset + +## Links + +- [Bermuda website](https://bermudabay.xyz/) +- [Documentation](https://docs.bermudabay.xyz/) +- [Architecture](https://docs.bermudabay.xyz/tech/architecture) +- [Contracts](https://docs.bermudabay.xyz/tech/contracts) +- [Compliance overview](https://docs.bermudabay.xyz/compliance-solution/how-compliance-works) +- [GitHub organization](https://github.com/BermudaBay) +- [GL1 white paper: Programmable Compliance, Box 5](https://global-layer-one.org/pdf/gl1-pc-whitepaper-22-jun-2026.pdf) +- [Linea × Bermuda settlement PoC](https://cryptobriefing.com/linea-bermuda-private-cross-chain-settlement/) +- [Utila x Bermuda partnership](https://utila.io/blog/utila-bermuda-confidential-custody-central-banks) From 9fdcf88c556242454614bd11ca4dda89c858e31a Mon Sep 17 00:00:00 2001 From: ethsystems-bot <321619048+ethsystems-bot@users.noreply.github.com> Date: Wed, 9 Sep 2026 10:13:50 +0000 Subject: [PATCH 2/3] docs(changelog): add Bermuda vendor entry for #191 --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index b5da0b4..9b0d327 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- feat(vendor): add [Bermuda](vendors/bermuda.md), a shielded-UTXO privacy layer for EVM chains with in-circuit issuer policy enforcement ([#191](https://github.com/ethsystems/map/pull/191)) - fix(vendor): [Privacy Pools](vendors/privacypools.md) -- v1 has been live on Ethereum mainnet since March 2025; replace the stale "not yet deployed at large scale" line and point the GitHub link at [0xbow-io/privacy-pools-core](https://github.com/0xbow-io/privacy-pools-core) (reported by 0xbow in [#92](https://github.com/ethsystems/map/pull/92)) - feat(vendors): add [Inco](vendors/inco.md) vendor page (TEE-based confidential compute — confidential ERC-3643, private vaults, shielded stablecoin payments); wire Inco into custody, funds-assets, and payments domains and the relevant TEE/privacy patterns ([#177](https://github.com/ethsystems/map/pull/177)) - feat(approach): link private-stocks, private-commodities, private-fx, and private-repo to [Private Trade Settlement](approaches/approach-private-trade-settlement.md), and private-treasuries to [Private Payments](approaches/approach-private-payments.md), as explicit variants ([#190](https://github.com/ethsystems/map/pull/190), part of [#138](https://github.com/ethsystems/map/issues/138)) From 9d64cac2d7cda21315a8263af075a7f9d359e0c7 Mon Sep 17 00:00:00 2001 From: ethsystems-bot <321619048+ethsystems-bot@users.noreply.github.com> Date: Wed, 9 Sep 2026 10:22:06 +0000 Subject: [PATCH 3/3] fix(vendor): address review comments on Bermuda card Applies the six inline comments from @rymnc on #191. - Title reworded to the suggested parenthetical form - What it is: adds the pluggable compliance model and BYOC configuration - Architecture: condensed, primitives moved down to Technical details - Architecture: adds the relayer, ERC-4337 and x402 submission path - Enterprise section: links four approaches and six use cases - Technical details: splits X25519 key agreement from XChaCha20-Poly1305 note encryption, and names BN254 and Grumpkin by role - Risks: adds relayer dependence, compliance engine dependence, governor powers, issuer clawback and unpublished proving cost Crypto and relayer facts sourced from docs.bermudabay.xyz (encryption-scheme, signing-scheme, tech/architecture, compliance-solution). --- vendors/bermuda.md | 113 +++++++++++++++++++++++++++++---------------- 1 file changed, 73 insertions(+), 40 deletions(-) diff --git a/vendors/bermuda.md b/vendors/bermuda.md index a1e79bf..8885104 100644 --- a/vendors/bermuda.md +++ b/vendors/bermuda.md @@ -8,7 +8,7 @@ last_reviewed: 2026-09-03 maturity: testnet --- -# Bermuda – Privacy and compliance layer for the EVM +# Bermuda (Privacy and compliance layer for the EVM) ## What it is @@ -21,6 +21,13 @@ Proof of Innocence, issuer policies and clawback are enforced by the smart contract and its circuits, not by an operator who reads transactions. It is middleware, not a chain, wallet or custodian. +Compliance is a pluggable module rather than a fixed rule set. An +integrator configures KYC/AML workflows, jurisdiction-specific rules and +custom policies without modifying the core protocol. Deposit screening is +delegated to an external compliance engine that the deployment chooses. +Two deployments under different regulatory regimes can therefore share one +privacy layer. + ## Fits with patterns - [Shielding](../patterns/pattern-shielding.md) @@ -42,42 +49,42 @@ middleware, not a chain, wallet or custodian. ## Architecture -- **Smart contract**: holds funds as shielded UTXOs: commitments in - an incremental Merkle tree, chain-bound nullifiers, one `transact` entry point. - Notes are encrypted to the recipient's x25519 key and emitted as events. -- **Proofs and keys**: Noir circuits, Barretenberg as ZK proving backend, - client-side proving in WASM. Spend authorization is Schnorr over Grumpkin; FROST - threshold Schnorr puts a Safe's owners behind a shielded account. -- **Issuer policy engine**: the token owner (typically a Safe) sets a - per-token policy — spending limit per period, allow and deny lists, an - optional issuer viewing key — that every transfer proves in-circuit against - the smart contract's live policy root. The circuit checks a commitment to the policy's - fields, so an issuer can publish its rules or keep them private; list - membership stays off-chain either way. The viewing key yields an encrypted - view of that token's transfers; the issuer can claw back funds with a proof. -- **Compliance Gateway**: deposits bind the compliance engine's key and an - expiry block into the proof, so a delisted address cannot replay an - approval. Flagged deposit ids live in an indexed Merkle tree: private - withdrawals prove exclusion, disclosed ones inclusion. Depositors and - recipients are also screened on-chain by the Chainalysis sanctions oracle. -- **Roles**: the smart contract and verifiers are non-upgradeable. A governor - sets fees, - recovery parameters and the public-withdrawal delay and assigns a pauser, - who halts `transact` and `claim` for incident response. -- **Cross-chain DvP**: two smart contracts act as escrows: a leg is locked, - released - once the counterparty's lock is proven present, or reclaimed on a proof of - absence after the cutoff — ERC-7888 broadcast proofs, no coordinator. Linea +- **Smart contract**: holds funds as shielded UTXOs. Commitments sit in an + incremental Merkle tree. Each spend publishes a nullifier bound to that + chain. Notes are encrypted to the recipient and emitted as events. +- **Proofs**: circuits are written in Noir. Proving runs on the user's own + device. +- **Issuer policy engine**: the token owner, typically a Safe, sets a + per-token policy covering a spending limit per period, allow and deny lists + and an optional viewing key. Every transfer proves in-circuit that it + satisfies the live policy. The circuit checks a commitment to the policy + fields, so an issuer can publish its rules or keep them private. List + membership stays off-chain in either case. The viewing key decrypts that + token's transfers. The issuer can claw back funds with a proof. +- **Compliance gateway**: a deposit binds the compliance engine's approval and + an expiry block into the proof. A delisted address cannot replay an old + approval. Flagged deposit ids are tracked in an indexed Merkle tree. A + private withdrawal proves the deposit is absent from that tree. A disclosed + withdrawal proves it is present. Depositors and recipients are also screened + on-chain by the Chainalysis sanctions oracle. +- **Submission path**: a Bermuda relayer submits shielded transactions on + behalf of users. ERC-4337 bundlers and an x402 facilitator cover gas + abstraction and agent payments. +- **Roles**: the smart contract and its verifiers are non-upgradeable. A + governor sets fees, recovery parameters and the public-withdrawal delay. The + governor assigns a pauser who halts `transact` and `claim` for incident + response. +- **Cross-chain DvP**: two contracts act as escrows. One leg locks, then + releases once the counterparty's lock is proven present. It is reclaimed on + a proof of absence after the cutoff. No coordinator sits in the path. Linea proof of concept, June 2026. -- **Products**: - - SDK suite: `core-sdk`, `issuer-sdk`, `safe-sdk`, `fireblocks-sdk`, etc. - - E2E apps: Private Safe Wallet, universal/mobile app in progress -- **Services**: - - E2E enterprise applications, from development through operations to compliance, for instance: - - Exclusive OTC/DvP/RFQ networks (always private, cross-chain capable) - - Customized private wallet UX, especially enterprise- and institution-focused - - Accounting/reporting and compliance adapters, and middleware - - MPC overlay upgrades on top of institutions’ physical HSMs through the partnership with Utila +- **Products**: SDK suite (`core-sdk`, `issuer-sdk`, `safe-sdk`, + `fireblocks-sdk`) and end-user apps (Private Safe Wallet, with universal and + mobile apps in progress). +- **Services**: enterprise delivery from build through operations to + compliance. Private OTC, DvP and RFQ networks. Institutional wallet UX. + Accounting, reporting and compliance adapters. MPC overlay on institutional + HSMs through the Utila partnership. ## Privacy domains @@ -104,12 +111,28 @@ middleware, not a chain, wallet or custodian. - **Asset management**: shielded ERC-4626 positions, private yield and DeFi, private order books +Related approaches: [Private Payments](../approaches/approach-private-payments.md), +[Atomic DvP Settlement](../approaches/approach-dvp-atomic-settlement.md), +[Private Trade Settlement](../approaches/approach-private-trade-settlement.md), +[White-Label Infrastructure Deployment](../approaches/approach-white-label-deployment.md) + +Related use cases: [Private Stablecoins](../use-cases/private-stablecoins.md), +[Private RWA Tokenization](../use-cases/private-rwa-tokenization.md), +[Private Treasuries](../use-cases/private-treasuries.md), +[Private Payments](../use-cases/private-payments.md), +[Private Repo](../use-cases/private-repo.md), +[Private Stocks](../use-cases/private-stocks.md) + ## Technical details -- Curves in use: BN254 (proof system), Grumpkin (signatures), Curve25519 (encryption) -- Proof system: Noir, Barretenberg (UltraHonk); no circuit-specific trusted setup (universal SRS) -- Signing: Schnorr, FROST, Golden DKG -- Encryption: XChaCha20-Poly1305 +- Proving curve: BN254. Grumpkin is its cycle partner and carries the spend + signatures +- Proof system: Noir with Barretenberg (UltraHonk). Universal SRS, so there + is no circuit-specific trusted setup +- Spend authorization: Schnorr over Grumpkin. FROST supplies the threshold + variant, keyed by Golden DKG +- Note key agreement: X25519 ECDH, with a fresh ephemeral keypair per note +- Note encryption: XChaCha20-Poly1305 under the derived shared secret Post-quantum implementation in progress. @@ -133,6 +156,16 @@ Post-quantum implementation in progress. - Testnet stage: no mainnet deployment, third-party audit or bug bounty published - Anonymity depends on activity in the contracts per chain and asset +- Relayer dependence: the Bermuda relayer sees submission metadata and can + censor or delay a shielded transaction. Self-submission is the fallback, + at the cost of network-level anonymity +- Compliance engine dependence: entry to the pool requires an approval from + an external screening provider +- Governor powers: fees, recovery parameters and the public-withdrawal delay + are governor-controlled. The pauser can halt transfers and claims +- Issuer powers cut both ways: freezing and clawback follow holders into the + shielded domain +- Client-side proving cost on constrained devices is not published ## Links