YadaCoin Bridge Audit: Transaction-Level Backing

The answer in 30 seconds

YadaCoin contracted Zealynx directly to review seven Solidity contracts connecting BNB Chain with the YadaCoin blockchain. The system combined native and ERC-20 transfers, wrapped tokens, beacon proxies, permit-driven batch operations, and a KERI-inspired key registry.

The pivotal lesson was that local validation did not guarantee transaction-level solvency. One native payment could satisfy multiple wrap checks because msg.value remains constant throughout a transaction. In a separate path, bridge reserves could be transferred without matching value from the caller. Zealynx traced value, token identity, and authorization across complete execution sequences. The public report records 28 findings and marks all of them fixed.

This is a technical engagement narrative based on the public security report and public audit record. It does not claim an exploit occurred or assign a monetary value to the risk.

The system-level security decision

A bridge does more than move tokens between two endpoints. It maintains a relationship between assets held in reserve, wrapped supply on another chain, token identity, user authorization, and the keys allowed to advance the system.

YadaCoin's reviewed implementation brought these responsibilities together in a single operation flow:

• native and ERC-20 transfers;
• wrapped-token minting and burning;
• ERC-2612 permit-driven batch execution;
• token-pair registration;
• KERI-inspired key inception and rotation;
• beacon-proxy deployment; and
• upgradeable bridge and registry contracts.

The review question was therefore not simply whether each contract worked in isolation. It was whether the connected system preserved the same security model through every transaction and upgrade path.

The dangerous assumption: every local check can pass while the bridge becomes underbacked

The bridge checked native value against individual recipients and permits. That sounds reasonable until the unit of accounting is examined.

msg.value belongs to the entire transaction. It does not decrease after one recipient or permit consumes part of it. A condition such as msg.value >= recipient.amount can therefore pass repeatedly even though the bridge received the native value only once.

Consider a transaction that supplies 100 units of native value:

1. The first permit requests a 100-unit wrap.
2. The check msg.value >= 100 passes.
3. The bridge mints approximately 100 wrapped units.
4. A second permit requests another 100-unit wrap.
5. The same check passes again because msg.value is still 100.
6. The bridge has received 100 units but minted approximately 200.

Each local comparison is true. The transaction-level backing invariant is false.

The correct question is not whether every wrap amount is individually covered. It is whether cumulative wrapped supply created by the transaction can ever exceed cumulative native value received.

How Zealynx investigated the bridge

Zealynx organized the review around complete state transitions rather than a checklist of isolated functions.

1. Follow value through the entire transaction

The review traced native value and ERC-20 balances across recipients, permit boundaries, remainder branches, wrapping, and unwrapping. This exposed places where per-operation validation diverged from transaction-level accounting.

2. Verify the identity of every asset representation

A wrapped token is trustworthy only if the bridge can prove which original asset it represents and who controls its mint and burn functions. The review therefore examined pair registration, beacon deployment, and the authority model of accepted wrapped-token contracts.

3. Trace authorization across key transitions

The KERI-inspired registry linked inception, confirming keys, and rotation. Zealynx followed the complete key event chain to determine whether valid users could continue operating and whether the intended actor remained authorized.

4. Retest neighboring paths after upgrades

A narrow correction can repair one transition while breaking another. The review tested both paired-key rotation and single-key onboarding after the registry upgrade rather than assuming the original fix was isolated.

The pivotal finding cluster

Bridge reserves could leave without matching caller value

A native-token remainder branch used the bridge's own balance without first proving that the caller supplied equivalent msg.value. A caller could construct a transfer-only operation with no recipients and no native payment, set the permit amount to the bridge balance, and cause the remainder logic to transfer native reserves.

The transfer primitive behaved as written. The failure was at the boundary between a signed operation, its declared amount, and transaction-level native value.

Verified consequence: the vulnerable path could transfer the bridge's native-token balance, leaving legitimate wrapped-native holders unable to redeem against those reserves.

Recorded resolution: YadaCoin corrected the native-value accounting, and the public audit record marks the finding fixed.

One payment could support multiple mint operations

The batch flow validated each native wrap against the same transaction-level msg.value. Because the accounting reset at permit boundaries, multiple permits could reuse one payment and mint more wrapped supply than the bridge received in native value.

Verified consequence: wrapped supply could exceed native reserves, and excess wrapped units could be redeemed against reserves deposited by other users.

Recorded resolution: cumulative native-value accounting was introduced across the transaction, and the public audit record marks the finding fixed.

Token identity was another side of the same solvency problem

Token-pair registration accepted a user-provided wrapped-token address without proving that it came from the bridge's trusted beacon or enforced bridge-controlled minting and burning. An untrusted caller could bind a legitimate original token to a malicious wrapped-token contract before the correct pair was registered.

This was not merely a registration issue. Backing depends on the bridge recognizing only authentic representations of the asset. If arbitrary wrapped units are accepted during unwrapping, legitimate reserves can be released without a corresponding trusted asset being surrendered.

Recorded resolution: token-pair registration was separated from user key operations, and wrapped-token deployment was restricted to the trusted bridge path. The public audit record marks the finding fixed.

A fix that broke a neighboring state transition

The key registry produced a second lesson about system-level review.

The original implementation derived a confirming-key hash from the wrong public key. Valid key-pair registration therefore reverted after inception. An upgrade corrected that variable, but computed the confirming-key hash before checking whether the operation actually contained a confirming key.

Single-key onboarding intentionally supplied no confirming key. The upgraded validation attempted to process the empty value and reverted, preventing new users from registering an inception key.

The targeted correction worked for paired keys while breaking the neighboring non-pair path.

Recorded resolution: confirming-key processing was moved inside the pair-specific branch. Zealynx verified the non-pair registration path after the correction.

Before, intervention, and verified after-state

The public audit record marks all 28 findings fixed. This is a point-in-time statement about the reviewed scope and recorded remediation, not evidence of a particular deployment and not a guarantee about later code.

What bridge teams can reuse from this engagement

The main lesson is that bridge security lives between functions. Teams preparing for deployment or an upgrade should test at least these questions:

1. Cumulative backing: Can several recipients or permits reuse one transaction-level payment?
2. Reserve isolation: Can any transfer branch spend bridge-held assets without proving caller-supplied value or valid redemption?
3. Token identity: Can an untrusted actor choose, replace, or pre-register the contract accepted as a wrapped asset?
4. Mint and burn authority: Can the bridge prove that every accepted wrapped token enforces the intended authority model?
5. Batch boundaries: Which counters reset per recipient, permit, operation, or transaction, and is that the correct accounting unit?
6. Key continuity: Can valid users complete inception and every later rotation without breaking the authorization chain?
7. Upgrade adjacency: Does a correction preserve both the targeted path and neighboring state transitions?

A bridge can pass function-level tests and still fail one of these system properties.

Impact and evidence limits

The public report supports the technical mechanisms, severity classifications, and recorded remediation statuses described here. It does not provide a dated, scoped monetary value for the bridge reserves exposed during the review.

For that reason, this Case Study does not equate protocol value or later TVL with money protected, saved, or loss avoided. The defensible outcome is narrower: the review identified reserve-drain, underbacking, token-identity, and onboarding failure paths, and the public audit record marks their corrections as fixed.

Public evidence

• YadaCoin Smart Contract Audit report
• Zealynx YadaCoin audit record
• Reviewed YadaCoin repository

No exploitation, deployment timing, or quantified commercial outcome is claimed.

Planning a bridge launch or upgrade?

Zealynx reviews whether value backing, token identity, authorization, key transitions, and upgrade behavior remain consistent across complete bridge operations. Explore our smart contract security audits or request a bridge review.

Frequently asked questions

What did Zealynx audit for YadaCoin?

Zealynx audited seven Solidity contracts supporting the BNB-to-YadaCoin bridge. The scope included the bridge, key registry, wrapped-token implementation, beacon and proxy contracts, ERC-2612 permit operations, and the interactions between those components.

Why was transaction-level accounting important?

msg.value remains constant throughout an EVM transaction. If each permit validates against the full value independently, several permits can reuse one payment. Bridge accounting must track cumulative native value across the complete transaction.

How could wrapped supply become underbacked?

Two native wrap permits could each pass against the same msg.value. The bridge could then mint more wrapped units than the native value it received, violating the reserve-backing invariant.

Why did wrapped-token identity matter?

A bridge should release reserves only in exchange for the authentic wrapped representation it controls. Accepting an untrusted wrapped-token contract could allow arbitrary units to be minted and redeemed against legitimate reserves.

Were the recorded findings fixed?

Yes. The public audit record marks all 28 findings fixed. The statement applies to the reviewed scope and evidence cutoff, not to later versions or deployment status.

How much money did the audit protect?

The public evidence does not establish a dated monetary value directly exposed through the findings. Zealynx therefore does not claim a specific amount protected, saved, or avoided.