Unaudited, unvetted, experimental. Do not use as a reference. AI-researched ratings that may be wrong; not advice or a statement of fact about any provider. Full disclaimer
Pending review. 1150 of 1150 ratings not yet checked by a human. Do not rely on unreviewed ratings.
zERC20 (zBNB on BNB Chain)
transfer Assessed on BNB Chain (chain 56)zerc20.io
Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: zERC20 is deployed on Ethereum, Arbitrum, Base, BNB Chain, Polygon and Kaia (docs Contract Addresses page). We read the token's own transfer counter index() on each chain on 2026-10-09: zBNB on BNB Chain 0x4388…5c54 had 17356 indexed transfers, against 451/250/111 for zETH and 193/419/394 for zUSDC on Ethereum/Base/Arbitrum. Unit: the zBNB token proxy, its Verifier, the shared Blocklist, the zBNB Hub and LiquidityManager on BNB Chain. Excluded: zETH, zUSDC and zJPYC deployments (same code, Base-hosted hubs) and the testnets.
Offered everywhere except the countries listed. Checked 2026-10-09. Not scored.
The terms define Restricted Countries as jurisdictions under OFAC, EU or UN sanctions "including but not limited to" North Korea, Iran and Syria; only those three are named, so only they are listed. The terms are governed by Swiss law. At protocol level, the token contracts have no country check but enforce an owner-maintained address Blocklist (C1, C4). The production app bundle has no IP or country gate (archived grep), and it pre-checks recipients against the onchain Blocklist.
Who can block valid use, and can users route around them?
0 FailsPillar rating: weakest of 5 1 of 5 Partial or better
What would raise this pillar
Admin pause or freeze powers reaching Weak: Role held by a multisig that misses one of those conditions (no timelock, undisclosed signers, bypass modules), or the constraints are documented only.
Settle without the provider reaching Weak: Partial (for example settle but not refund or withdraw), or documented only.
Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The settlement contracts carry two stop powers. The Blocklist owner, a 3-of-4 Safe with undisclosed EOA signers, can add any address at once, with no timelock or notice. The token then refuses every transfer to or from that address, including funds already sitting at a burn address meant for that recipient. The Verifier owner, a second 3-of-4 Safe with the same signers, can pause all proofs and teleports with activateEmergency. Neither Safe has a module or a guard. Scored 0 because the role can target individual addresses with no notice. The docs say the list follows OFAC; that is a policy statement, not a constraint in code.
Evidence (5)4 verified · 1 documented
Verified
_update() reverts with AddressIsBlocked if from or to is on BLOCKLIST, so every transfer, mint, burn and teleport of a listed address fails. This file is identical, apart from a trailing newline, to the Sourcify source of the deployed implementation 0x857a…c748.
The Blocklist (Sourcify exact_match) has onlyOwner blockAddress, unblockAddress and blockAddresses with no delay; owner() is the Safe 0x4301…B1fa at block 126599703.
Safe 1.4.1 with threshold 3 and four owners (0x6893…2647, 0x5C04…4Bb6, 0x1eB7…794D, 0x4E3a…6830, all EOAs); getModulesPaginated returns no modules and the guard slot is zero. The Verifier owner Safe 0xb6d8…DafCa has the same four owners, threshold 3, no modules and no guard.
The zBNB Verifier's owner is the Safe 0xb6d8…DafCa and paused() is false. Its implementation 0x6b4a…E1c8 has the same code hash on BNB Chain as on Base, where Sourcify has an exact match. In that source, activateEmergency() lets the owner pause proveTransferRoot, teleport, singleTeleport and relayTransferRoot.
Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The payer's half is direct: the sender transfers zBNB to a burn address with any wallet. The payee's half is not. teleport and singleTeleport are open to anyone with a valid proof, but they verify against transfer roots, and only addresses the Verifier owner has allowlisted can post those roots. A payment that has not been included in a proved root cannot be redeemed until the provider's prover posts it. Judgment call: we score the private flow, so 0, because settlement depends on the provider's prover. A plain public zBNB transfer settles directly, but it is not private.
Evidence (2)2 verified
Verified
proveTransferRoot() is gated by onlyAllowedProver, which requires msg.sender to be in an owner-managed allowlist (setAllowedProver L775-L780). Teleports verify against roots recorded only by this function or relayed from the Hub.
The deployed Verifier implementation (exact match on Base, same code hash on BNB Chain) keeps the onlyAllowedProver gate on proveTransferRoot. latestProvedIndex() equalled the token's index() (17356) at block 126599703, so roots were being proved at the time.
Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Two provider services sit in the required path. The root prover is single-vendor by contract design: only allowlisted addresses can prove roots. The hosted indexer supplies the Merkle proofs recipients need. The docs invite users to run their own indexer, but the official repository is not public. A snapshot of the monorepo, BUSL-1.1, exists under a personal GitHub account; it is not linked from the org, and running a prover from it would not help, because the contract allowlist still applies. The relay node and ICP canisters are optional. Scored 0: required, closed and single-vendor.
Evidence (3)1 verified · 2 documented
Verified
Root proving is restricted to allowlisted provers, so the provider can stop new payments from becoming redeemable.
Recipients get Merkle proofs for their burn events from the indexer; the app bundle hardcodes https://v1.mainnet.api.zerc20.io/indexer/zbnb (archived bundle strings).
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Documented
The docs point to github.com/zerc20io/zERC20 for the CLI, indexer and prover code, but that repository returned 404 on 2026-10-09. The org has one public repo, its profile.
Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Filtering is built into the settlement contracts. The token checks every sender and recipient against an owner-maintained Blocklist, so no direct path avoids it. The filter is disclosed in the docs, and the list source is named as OFAC, but its contents are set by the owner Safe. The terms describe these parameters as operating "without human intervention or discretion by the Operator", which the owner-only blockAddress function contradicts. Judgment call: anchors 2 and 3 require a neutral settlement layer. The filtering is disclosed, so not 0. We take 1.
Evidence (2)1 verified · 1 documented
Verified
Address filtering sits in the token's _update(), which is the settlement layer.
The FAQ and contract spec disclose the OFAC Blocklist and its effect; the app also pre-checks recipients against the Blocklist before sending (docs Private Transfer page).
Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Tokens and chains are enumerated onchain and in the docs. zBNB wraps native BNB, which has no issuer freeze. The freeze power that matters is zERC20's own Blocklist (C1), which the docs disclose. The docs do not state BNB Chain's validator-set assumptions or LayerZero's DVN trust for cross-chain roots. Scored 2: enumerated in code, chain and messaging assumptions not stated.
Evidence (2)1 verified · 1 documented
Verified
underlyingToken() of the zBNB LiquidityManager returns the native-token sentinel 0xEeee…EEeE (native BNB), and the token's verifier() and minter() point at the listed Verifier and LiquidityManager.
Does the deployed bytecode match public source, and can a third party rebuild it? O1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Most of the zBNB contracts are verified on Sourcify, but the Verifier implementation, which every redeem calls, is not verified on BNB Chain. Its bytecode matches a verified deployment on Base. BscScan blocked automated access, and we did not bypass it. The official repository is not public, so there is no build script from a provider-published commit. Judgment call: 1 rather than 2, because one settlement contract is unverified on this chain.
Evidence (2)2 verified
Verified
The token proxy's implementation slot reads 0x857a…c748. On chain 56 Sourcify returns exact_match for the zERC20 implementation, the LiquidityManager implementation 0x0403…53bd, the Blocklist and the Hub proxy; match (partial) for the token, Verifier and LiquidityManager proxies and the Hub implementation; and no record for the Verifier implementation 0x6b4a…E1c8.
The Verifier proxy's implementation slot reads 0x6b4a…E1c8, whose runtime code hash (0x452b52…d697) equals that of the exact-matched contract at the same address on Base.
Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Officially, only the contracts (as Sourcify source) and the compiled MIT SDK on npm are public. The docs' repository link returns 404. A full-stack snapshot exists under an unaffiliated personal account; we cite it only where it matches deployed bytecode and do not treat it as the provider's published stack. Judgment call: 1 (contracts and SDK only).
Evidence (2)2 verified
Verified
The zerc20io org has one public repository, its profile README, which links the app, docs and website and no source repository.
A personal-account repository holds a BUSL-1.1 snapshot (2026-04-20) of the monorepo, with contracts, cli, sdk, frontend, indexer, decider-prover, relay and zstorage. Its zERC20.sol and Blocklist.sol match the deployed source; its Verifier.sol is an older version.
Can a stranger reach a working deployment from the README? O3
0 Fails
Sets the pillar ratingBest evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The documented path to a working deployment starts from a repository that is not public, so a stranger cannot follow it. We made no reproduction attempt. Even with code, a self-hosted prover could not post roots to the deployed Verifier without being allowlisted. Scored 0, because no published path exists.
Evidence (1)1 documented
Documented
The CLI and self-host instructions start by cloning github.com/zerc20io/zERC20, which returned HTTP 404 on 2026-10-09.
Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4
1 Weak
Best evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
ABIs ship in the npm package, and the API and events are described on GitBook, but none of it is versioned in a public provider repository. We found no payee export function. Scored 1: documented only.
Evidence (1)1 documented
Documented
The indexer API, contract spec and events are documented on the hosted docs site; the npm SDK ships contract ABIs (BlocklistArtifact and others).
Does every repository needed to run the product carry an OSI-approved license? F1
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The token and Verifier source is BUSL-1.1 with no additional use grant, so production use of a fork needs a commercial licence until 2030. The required root prover and indexer are not public. Scored 0: required components are closed, and the core contracts are source-available only.
Evidence (1)1 verified
Verified
Business Source License 1.1, Licensor zERC20, no Additional Use Grant, Change Date 2030-04-08, Change License GPL-2.0-or-later. The deployed zERC20.sol and Verifier.sol carry SPDX BUSL-1.1 in their Sourcify source; Blocklist, Hub and LiquidityManager are MIT.
Can the provider unilaterally relicense future versions, and has it committed not to? F2
? No evidence
Sets the pillar rating
UnreviewedAssessed by AI research agent (seed), 2026-10-09
No checkable evidence settles this yet, so it counts as 0.
The official repository is not public, so its CLA, contributing rules and licence history cannot be checked. The snapshot's LICENSE sets a 2030 change date to GPL-2.0-or-later.
Does a production deployment need a proprietary plugin or hosted-only service? F3
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Using the deployed protocol requires the provider's root prover, a hosted-only service by contract design, and the indexer code is not officially public. The docs describe both services. Scored 1: production needs a hosted service with no open alternative, documented.
Evidence (2)1 verified · 1 documented
Verified
The prover allowlist is set by the owner; no open alternative can post roots to the deployed Verifier.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Privacy
What can an observer learn, and did the user knowingly choose it?
1 WeakPillar rating: weakest of 5 1 of 5 Partial or better
What would raise this pillar
Tracking and analytics reaching Partial: Present, off by default, opt-in visible in code.
Data collected beyond payment reaching Partial: Additional fields are either optional and clearly optional in code, or legally required, limited to that requirement, and disclosed with their legal basis in code or a versioned repo document.
Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1
1 Weak
Sets the pillar ratingBest evidence: DocumentedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Neither the served app bundle nor the SDK package contains analytics; the app explicitly disables Reown's analytics. The app source is not public, and the SDK is published only as compiled npm output, so this rests on documented-tier reads of build artefacts. No trace was run. Judgment call: the substance fits 2 or 3, but without verified or trace evidence the documented cap applies, so 1.
Evidence (2)2 documented
Documented
The production bundle passes analytics:false to Reown AppKit, and a grep finds no analytics, error-reporting or fingerprinting SDK. The npm SDK (0.7.5) has no such dependency.
Does the flow collect anything beyond addresses, amounts, token, and chain? P2
1 Weak
Sets the pillar ratingBest evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Onchain, the flow needs only addresses and amounts, and burn-address secrets are delivered encrypted through ICP canisters. The required hosted indexer, however, learns which recipient is querying which burn events, and with them the IP address and timing. That is collection beyond settlement needs, disclosed only in docs. Scored 1.
Evidence (1)1 documented
Documented
The trust model says the indexer operator sees sender, burn address and value, and learns the recipient when the recipient queries it.
What do calldata and events reveal about who paid whom for what? P3
2 Partial
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The chain shows the sender paying an unknown burn address, and later a recipient minting via teleport, with no onchain link between the two. Amounts are plaintext and not fixed denominations, so unusual amounts and timing can link a payment to its redeem; the docs say so. Judgment call: 2 (minimal linkage, documented) rather than 3, because plaintext arbitrary amounts are revealed by the protocol itself. Anonymity-set size (17356 indexed zBNB transfers) is behavioural and not scored.
Evidence (2)1 verified · 1 documented
Verified
Every balance change emits IndexedTransfer(index, from, to, value) in plaintext, and a redeem emits Teleport(to, value); the burn address is trim160(poseidon(recipient, secret)), so it does not reveal the recipient.
Which third parties see a request during a payment, and can they be swapped out? P4
1 Weak
Sets the pillar ratingBest evidence: DocumentedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
In the app flow, the provider's indexer, Alchemy (or thirdweb) RPCs and ICP boundary nodes see payment requests, and WalletConnect relays see wallet sessions. The SDK leaves every endpoint to the integrator, but the indexer it needs is the provider's unless you build your own. Disclosed in docs; the app's choices are not swappable. Scored 1.
Evidence (2)2 documented
Documented
The app hardcodes the zERC20 indexer and relayer, Alchemy RPC URLs with an embedded key, a thirdweb BNB RPC, ICP API hosts and WalletConnect/Reown hosts.
Can RPC and indexer URLs be changed, and is the indexer code public? P5
1 Weak
Sets the pillar ratingBest evidence: DocumentedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
In the SDK, endpoints are configurable in code. The app hardcodes them. The indexer code is not officially public. Judgment call: the SDK would support 2, but the evidence is a compiled npm package (documented tier), so 1.
Evidence (1)1 documented
Documented
The SDK hardcodes no service URL (only explorer links); indexer, decider, relay, ICP and RPC endpoints are passed in by the integrator.
Who holds funds between payer and payee, and can the provider redirect them? S1
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
In flight, value sits as a zBNB balance at a keyless burn address until the recipient teleports an equal amount. No provider wallet holds it, but the token and Verifier are upgradeable by 3-of-4 Safes with no timelock. The owner can also swap the Verifier or minter, which could redirect or invalidate pending balances. The BNB backing sits in an upgradeable LiquidityManager administered by the same Safe. Disclosed in docs. Scored 1: upgradeable escrow, disclosed.
Evidence (2)1 verified · 1 documented
Verified
The zBNB token is an ERC1967 UUPS proxy whose owner is the Safe 0x4301…B1fa; _authorizeUpgrade is onlyOwner, and setVerifier and setMinter (onlyOwner) choose which contracts can mint.
Who can change the contract code, and with how much notice? S2
1 Weak
Best evidence: VerifiedChecked 2026-10-19 today
UnreviewedAssessed by AI research agent (seed), 2026-10-09
All core contracts are UUPS proxies upgradeable at once by two 3-of-4 Safes that share the same undisclosed EOA signers. There is no timelock and no notice channel. Neither Safe has a module or a guard. Scored 1: multisig admin, no timelock.
Evidence (2)2 verified
Verified
The upgrade owner of the token, Blocklist and LiquidityManager is this Safe (3-of-4, EOA signers), with no modules and the guard slot at zero. No timelock contract sits in front of it.
How large an allowance does the SDK ask users to grant, and for how long? S3
1 Weak
Best evidence: DocumentedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The SDK requests exact-amount approvals, and the zBNB payment path needs none. Gasless redeem uses a signed fee authorization rather than an allowance. Judgment call: the code fits 3, but it is read from a compiled npm package, not a public repository, so the documented cap gives 1.
Evidence (1)1 documented
Documented
SDK wrap and unwrap approve exactly the amount being wrapped or unwrapped to the LiquidityManager, and only when the current allowance is short. zBNB wraps native BNB, which needs no approval, and a private send is a plain transfer.
If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4
0 Fails
Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
Derived from S1=1, C2=0, C3=0 and O3=0. If the provider disappears, no new roots are proved. Payments sent to burn addresses after the last proved root cannot be redeemed, and earlier unredeemed ones need indexer data that only the provider serves. Holders of plain zBNB can still unwrap through the LiquidityManager. Scored 0: payees' access depends on provider liveness.
Evidence (1)1 verified
Verified
Teleports verify only against roots posted by allowlisted provers (C2), and the Verifier owner can pause (C1).
Are secrets kept out of client bundles and are webhooks signed and verified? S5
1 Weak
Best evidence: DocumentedChecked 2026-10-09 10 days ago
UnreviewedAssessed by AI research agent (seed), 2026-10-09
The only secret seen in the client is an RPC provider key, which grants RPC quota. There are no webhooks or merchant API keys. Burn-address secrets stay with the user or are sent encrypted through ICP. Judgment call: this is a minor issue (2 in substance), but the evidence is a documented-tier read of a built bundle, so 1.
Evidence (1)1 documented
Documented
The served app bundle embeds one Alchemy key in six RPC URLs. Burn secrets and recipient keys are derived client-side, and gasless redeem uses an EIP-712 fee authorization signed by the recipient.
Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6
? No evidence
Sets the pillar rating
UnreviewedAssessed by AI research agent (seed), 2026-10-09
No checkable evidence settles this yet, so it counts as 0.
The docs and website name no audit or bug bounty. The personal-account snapshot contains audit/zksecurity-audit.pdf, but we could not extract its text to confirm scope or an audited commit, and the official repository is not public.
Security audits 1
Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.
zERC20 proof-of-burn R1CS circuits (withdraw, root transition, burn address, Merkle and Poseidon gadgets) and the Solidity contracts (zERC20, Verifier, Hub) at 69537e9569 Audited the zk-audit-target release. zERC20.sol, Verifier.sol, Hub.sol, Blocklist.sol and LiquidityManager.sol all differ between the audited commit and b890773c, so the deployed contracts include unaudited changes. The same report is at audit/zksecurity-audit.pdf in the snapshot repository.
Partly
3 low, 3 informational
Compiled from: zerc20.io and its docs (no audit named), the audit/ folder of the snapshot repository github.com/kbizikav/zERC20, and zkSecurity's public report index, which publishes the same audit for INTMAX. Audited contract sources were compared with the snapshot commit b890773c that this file matches to the deployed contracts. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.
Operational and procurement
Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.
Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 14 evidenced, 0 attested, 5 absent, 5 not applicable, 21 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.
Group A: operational facts
Fees
Evidenced
Component
Paid by
Amount
Basis
provider
payee
Redeem fee 35 bps of the newly redeemable amount, rounded up (contract maximum 100 bps)
redeemFeeBps on the zBNB Verifier, set per Verifier by its owner Safe; accrues in redeemFeeBalance and is minted to feeRecipient (the Verifier owner Safe 0xb6d8…DafCa) on withdrawal.
provider
payee
Relay fee on gasless redeems, quoted by the zERC20 relay node and deducted after the redeem fee
Optional; a recipient with BNB for gas can redeem directly. Quotes are dynamic and not published.
provider
none
No wrap or unwrap fee for zBNB (dynamic liquidity fees apply to zUSDC and zETH only)
Docs fee table; wrap and unwrap of zBNB happen only on BNB Chain, so no cross-chain balancing fee.
network
both
BNB Chain gas for the transfer to the burn address and for a direct redeem; LayerZero fees cross-chain
Not set by the protocol. No gas sample recorded (BSC public RPCs refuse historical log queries).
Verified
redeemFeeBps() returns 35 and feeRecipient() returns 0xb6d8B261948B097069eF926475cbB6dd698DafCa at block 126643625. The implementation source (exact match on Base, same code on BNB Chain) caps the fee at MAX_REDEEM_FEE_BPS = 100 and rounds up.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Custody model
Evidenced
Self-custody
Agrees with S1 (score 1). In flight, value sits as zBNB at a keyless burn address until the recipient redeems; no provider wallet holds it, and wrapped BNB sits in the LiquidityManager. The disclosed risk is that 3-of-4 Safes can upgrade the token, Verifier and LiquidityManager with no timelock, swap the Verifier or minter, and block addresses.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Licences and registrations
Absent
Searched: terms, privacy policy, docs (llms-full.txt) and Zefix. Not searched: FINMA's register of authorised institutions and SRO member lists (interactive searches).
Documented
Terms (last updated 5 February 2026) say the Operator is not a financial institution, money services business or VASP and cite no licence.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
First deployment
Evidenced
2026-02-04 (block 79259750): zBNB token proxy 0x4388…5c54 on BNB Chain, created through factory 0x29c8…281d in tx 0xc1880e18…7909 sent by 0xc692…49ac, with first implementation 0xda2f…acb8.
Verified
The app's token config gives deployed_block_number 79259750 for zBNB on BNB Chain; eth_getBlockReceipts for that block (bsc-dataseed) shows tx 0xc1880e18a029867dfee46087c5a199644d23a65487d457a3edb24979147f7909 emitting the proxy's first Upgraded (implementation 0xda2fd3a6979d5304bc36aab4d1f17b8b82bcacb8), OwnershipTransferred (to 0xc69251d8…49ac) and Initialized logs. Block dated 2026-02-04 13:40:30 UTC. Sourcify has no creation data for the proxy.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Operating entity
Evidenced
Ryodan Systems AG, CH-ZG · CHE-291.471.162 · register
The terms define an unnamed "Operator" of the app, website and docs; only the privacy policy names Ryodan Systems AG. Who holds the owner Safes is not stated.
Documented
The privacy policy (18 February 2026) names the operator of the website and app.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Security incidents
Unknown
Absence of a found incident is not evidence that none occurred.
Searched: docs (llms-full.txt, FAQ, support), terms and website. The official repository is not public, so there is no advisory channel to check; EmergencyTriggered and ActivateEmergency logs on the Verifier could not be scanned (no archive BSC RPC). paused() is false today.
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Product changes affecting users
Evidenced
2026-02-04: zBNB token proxy deployed with implementation 0xda2f…acb8, owned by the EOA 0xc692…49ac. source
2026-02-05: Terms of Use last updated (privacy policy dated 2026-02-18). source
2026-04-15: zERC20 implementation 0x857a…c748 deployed (block 92624068); the token proxy now points to it, so the token was upgraded on or after this date (upgrade transaction not located). source
Upgrade, owner-transfer, blocklist and fee-change logs could not be listed because public BSC RPCs serve no archive logs; the docs mention a migration of older Verifiers to the redeem-fee version without a date.
Verified
Sourcify creation data gives block 92624068 (2026-04-15 05:41:04 UTC) for the implementation and 92449195 (2026-04-14 07:48:05 UTC) for the Blocklist, both from 0x5eF8…17d3; the initial implementation in the proxy's deploy receipt was 0xda2f…acb8.
checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09
Volume transacted (verified only)
Unknown
not computed on 2026-10-19: no blocks-per-day estimate for chain 56
Teleport and TeleportWithRelayerFee carry the same amounts but split across two topics; RedeemFeeAccrued is emitted on both paths. Not computed; BSC log ranges need an archive RPC (RPC_56).
UnreviewedAssessed by AI research agent (operational), 2026-10-09
Group B: institutional due diligence
Control
State
What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?
Unknown
No ISO 27001 statement for Ryodan Systems AG in the terms, privacy policy or docs.
B1.2 ISO 27001, hosting and support organisation Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?
Unknown implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?
Unknown
No SOC 2 or ISAE report or statement of availability found.
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?
Unknown
The docs and website name no audit. A personal-account snapshot of the monorepo contains audit/zksecurity-audit.pdf, which was not read (CROPS S6 is unknown for the same reason).
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?
Unknown
No penetration test of the indexer, prover, relay node or app found.
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?
Unknown implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?
Absent
none of 2 repo(s): kbizikav/zERC20 ✗ no security policy file; zerc20io/.github ✗ no security policy file source 1 · source 2
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?
Unknown
No security policy, disclosure page or patch timelines found; the official repository is not public.
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?
Evidenced
some of 2 repo(s): kbizikav/zERC20 ✓ dependabot config present; zerc20io/.github ✗ no scanning config or workflow step found source 1 · source 2
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?
Unknown
The terms and privacy policy contain no incident-notification commitment.
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?
N/A: no such service implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?
N/A: no such service implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?
Unknown
No status page or post-mortem found.
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?
N/A: no such service implied from the component list
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?
Unknown implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?
Unknown implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?
Unknown implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?
N/A: no such service implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?
Evidenced
The indexer is a public, unauthenticated read API with IP-based rate limits; the ICP storage layer requires EVM signatures for key requests. No OAuth or JWT. source 1
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?
Unknown implied from the component list
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?
Unknown implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?
Unknown implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?
Unknown implied from the component list
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?
Unknown implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?
Evidenced
No fixed periods; personal data kept as long as needed for its purpose or legal requirements, then deleted or anonymised. Covers the website and app only. source 1 CROPS P2
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?
Evidenced
Ryodan Systems AG is the controller for website and app data under the Swiss FADP and GDPR; service providers are listed by type. No DPIA mentioned. source 1
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?
Unknown implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?
Unknown implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?
Unknown implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?
Unknown implied from the component list
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?
Evidenced
some of 2 repo(s): kbizikav/zERC20 ✓ deployment configuration: docker-compose.yml; zerc20io/.github ✗ no deployment configuration source 1 · source 2
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?
Evidenced
some of 2 repo(s): kbizikav/zERC20 ✓ rules: deletion, non_fast_forward, pull_request; zerc20io/.github ✗ no branch rules visible (classic branch protection is not readable without push access) source 1 · source 2
B9.2 CI runs on pull requests Does every pull request trigger automated checks?
Evidenced
some of 2 repo(s): kbizikav/zERC20 ✓ 3 workflow file(s); zerc20io/.github ✗ no .github/workflows source 1 · source 2
B9.3 Tests run in CI Do the CI workflows run the test suite?
Evidenced
some of 2 repo(s): kbizikav/zERC20 ✓ test command in a workflow; zerc20io/.github ✗ test command in a workflow source 1 · source 2
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?
B9.5 Versioned releases Are releases tagged with immutable semantic versions?
Absent
none of 2 repo(s): kbizikav/zERC20 ✗ latest tags: zk-audit-target, contract-audit, audit-target; zerc20io/.github ✗ no tags source 1 · source 2
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?
Evidenced
all of 2 repo(s): kbizikav/zERC20 ✓ 10 of 10 recent commits signed; zerc20io/.github ✓ 1 of 2 recent commits signed source 1 · source 2
B9.7 Changelog Is a changelog maintained with the code?
Absent
none of 2 repo(s): kbizikav/zERC20 ✗ no changelog or release notes; zerc20io/.github ✗ no changelog or release notes source 1 · source 2
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?
Absent
none of 2 repo(s): kbizikav/zERC20 ✗ none found; zerc20io/.github ✗ none found source 1 · source 2
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?
Evidenced
Logical and integration views on the docs site (architecture overview of contracts, off-chain services and ICP storage; contract, ZKP and ICP specs; SDK and indexer API). No infrastructure view of the hosted prover, indexer or relay node. Not versioned in a public provider repository. source 1 CROPS F3
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?
Evidenced
Ryodan Systems AG (CHE-291.471.162), Zug, per the privacy policy; the terms name only an "Operator", under Swiss law with Swiss Arbitration Centre arbitration seated in Zurich. source 1 · source 2
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?
Evidenced
Onchain redeem fee (35 bps on zBNB) accrues to the Verifier and can be minted to the fee recipient, the 3-of-4 owner Safe; liquidity fees on zUSDC and zETH fund wrap rewards. No other funding source is published. source 1
B11.3 Termination terms What happens to customer funds and data on termination by either side?
Evidenced
The Operator may suspend or end access to the app and APIs for violations, suspected illegality or security reasons, with an appeal by email; the terms say onchain access cannot be terminated, but the owner-managed Blocklist can freeze an address in the token (C1). source 1 CROPS C1
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?
Evidenced
Compliance in the payment path is an owner-maintained address Blocklist (said to follow OFAC) checked on every token transfer, and the app pre-checks recipients against it. No automated scoring, vendor screening or AI is described. CROPS C4 · CROPS C1
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?
N/A: no such service
The only screening is a manually maintained address list; no AI component is described (B12.1).
Unit: zBNB on BNB Chain (most indexed transfers of any zERC20 deployment on 2026-10-09). All BNB Chain reads are at block 126599703 via bsc-rpc.publicnode.com, which serves only very recent state. The docs' source link (github.com/zerc20io/zERC20) returned 404. We cite a BUSL-1.1 snapshot at github.com/kbizikav/zERC20 (commit b890773c, 2026-04-20; author Akira Taniguchi). The org does not link it, so we use it only where its files match deployed Sourcify source (zERC20.sol, Blocklist.sol) or show the same gate (Verifier prover allowlist). The SDK and the served app bundle were read as build artefacts (archived) and never installed or run. The Verifier implementation is unverified on BNB Chain but byte-identical to a Sourcify exact match on Base. No transactions or traces.
