Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Zera Bridge Info

No website provided

TBA

Zera Bridge Logo
Onboarded date 16/11/2025

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

80.00
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Rust / Solana
Onboard date 2025/11/17
Revision date 2025/11/17

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is renounced

The contract does not include owner functions that allow post-deployment modifications.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Ownership Privileges
  • The Guardians can authorize the release of native Zera tokens for a user on the Zera bridge, based on a validated lock_sol event from Solana.
  • The Guardians can authorize the creation of a new wrapped Solana token contract on Zera for a user, based on a validated lock_spl event from a first-time asset deposit.
  • The Guardians can authorize the minting of existing wrapped Solana tokens for a user on the Zera bridge, based on a validated lock_spl event from a subsequent asset deposit.
  • The Guardians can authorize the release of native Zera tokens for a user on the Zera bridge, based on a validated burn_wrapped event from Solana.
  • The Guardians can execute a pause or unpause of the Solana bridge, based on a validated VAA originating from the Zera governor.
  • The Guardians can execute an upgrade of the Solana token bridge contract, based on a validated VAA originating from the Zera governor.
  • The Guardians can execute an upgrade of the Solana core bridge contract, based on a validated VAA originating from the Zera governor.
  • The Guardians can execute a change to the guardian set on the Solana bridge, based on a validated VAA originating from the Zera governor.
  • The Guardians can execute a change to the per-transaction and 24-hour value limits on the Solana bridge, based on a validated VAA originating from the Zera governor.
  • The Guardians can execute an emergency reset of the rate limits on the Solana bridge, based on a validated VAA originating from the Zera governor.

The project maintains ownership of wrapped token mints via the Bridge Program PDA to ensure upgradability and emergency response capabilities. This architecture mirrors industry standards (e.g., Wormhole) and is strictly governed by the decentralized Guardian multi-sig via Verified Action Approvals (VAAs). No single entity possesses unilateral control; ownership retention is a deliberate security feature to allow for critical vulnerability patching.

Note - This audit report consists of a security analysis of the Bridge contract. This analysis did not include functional testing (or unit testing) of the token’s logic. Furthermore, we only audited the mentioned contract associated with this project. Other contracts related to this project were not audited by our team. We recommend investors conduct their own research before engaging with the token.

Files and details

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Findings and Audit result

Critical
High
Medium
Low
Optimization
Informational
high Issues | 1 findings

Resolved

#1 high Issue
Rate Limit Bypass for First-Time Asset Transfers
zera_bridge_token/src/lib.rs
L61-143
L145-266,
Description

The contract's rate-limiting mechanism, a cornerstone of its economic security, is critically flawed when handling the first-time transfer of any asset. The get_usd_value helper function, which is responsible for pricing transactions, defaults to a value of zero if a token's price is not found in the token_price_registry. Since the registry is only populated with prices by the Guardians during incoming transfers, any asset that has never been bridged before will have no price and will therefore be valued at $0. This allows an attacker to call lock_spl or lock_sol with a catastrophically large amount of a new token (e.g., $50 million). The contract will value this transaction at $0, causing both the per-transaction and 24-hour rate limit checks to pass trivially. This vulnerability creates a gaping hole in the bridge's security model, as it allows the complete bypass of its most important economic safeguard for the first transfer of any token. An attacker acquires a large amount of any SPL token not previously bridged. They call lock_spl. The contract fails to find a price, values the transaction at $0, and allows the multi-million dollar lock to succeed. The Guardians, seeing a valid lock, will then issue a VAA. This VAA is processed by the Zera-side create_sol function which, as identified in a separate critical finding, is also missing a rate limit check, completing the end-to-end bypass and creating a massive, uncontrolled liability on the Zera chain.

Comments

The get_usd_value function must be refactored to fail-safe. It must not default to a price of zero. If a price for a given token mint is not found in the token_price_registry, the function must revert the entire transaction with a clear error, such as PriceNotFoundForNewAsset. This change is critical and enforces a secure policy: an asset cannot be bridged out from Solana until a price for it has been established in the registry by the Guardians during a prior incoming transaction. This closes the loophole and ensures every outgoing transfer is checked against a known, Guardian-attested price.

medium Issues | 3 findings

Resolved

#1 medium Issue
Failure to Validate Zera Address Format Allows for Permanent Fund Loss
zera_bridge_token/src/lib.rs
L145-266
L61-143
L1031-1137
Description

All three "outgoing" functions that allow a user to send assets from Solana to Zera (lock_spl, lock_sol, burn_wrapped) accept a destination zera_address as a raw byte vector. The only validation performed on this critical input is a basic length check and a check for valid UTF-8 encoding. There is no check to ensure that the resulting string is a syntactically valid Zera address. This creates a high-risk scenario for user error. A user who provides a malformed destination address due to a typo or copy-paste error will still have their transaction succeed on the Solana side. Their funds will be permanently locked in the bridge's vault, and an event will be emitted with the invalid address. The Guardians will be unable to process this event on the Zera side, and because there is no mechanism to reverse a successful lock or burn on Solana, the user's funds will be permanently and irretrievably lost.

Comments

A robust validation check must be implemented on the zera_address (or zera_recipient) parameter in all three outgoing functions. This check must be performed at the beginning of each function, before any funds are moved. The validation logic should confirm that the provided address string conforms to the specific format of a valid Zera wallet (e.g., correct prefix, character set, and length, based on the Zera chain's official specification). If the address is found to be invalid, the function must revert immediately with a clear error message. This will prevent a user from locking or burning their funds without a valid destination, thus completely eliminating this vector for permanent fund loss.

Resolved

#2 medium Issue
mint_wrapped Function Fails to Emit a Success Event
zera_bridge_token/src/lib.rs
L591-1030
Description

The mint_wrapped function, after successfully creating and/or minting a wrapped token on Solana, completes without emitting any on-chain event or log. This is a significant omission, as every other value-transfer function in the entire bridge system correctly emits a detailed event upon success. This failure of transparency makes it extremely difficult for off-chain indexing services, monitoring tools, or even users to track the flow of newly wrapped assets onto the Solana side of the bridge. A //TODO: add event logging comment on line 1027 confirms that the developers were aware of this omission but did not implement it.

Comments

A msg! macro call must be added at the end of the mint_wrapped function, before the final Ok(()). This message should log a structured event, for example in JSON format, containing all the relevant details of the transaction. This should include, at a minimum, the event name (e.g., "Mint_Wrapped"), the original zera_contract_id, the new or existing wrapped_mint address, the amount minted, and the recipient's address.

Resolved

#3 medium Issue
Centralization of Power in the Guardian Set
zera_bridge_token/src/lib.rs
L1-1795
Description

The entire security model of the Zera-Solana bridge is fundamentally centralized around the authority of a small, trusted set of Guardians. These entities have unilateral and cryptographically-enforced power over all core functions of the bridge. This includes the sole authority to authorize the minting of wrapped assets and the release of locked native tokens, as well as the power to execute all administrative actions such as pausing the bridge, upgrading its core smart contracts, and even changing their own membership. This architecture requires users to place their full trust not in decentralized code, but in the operational security and honesty of the Guardian operators. If a threshold of the Guardians' private keys were to be compromised or if the Guardians were to act maliciously, they could unilaterally mint infinite tokens, steal all user funds locked in the bridge vaults, censor transactions, or perform a hostile takeover of the entire system.

Comments

As this is a fundamental architectural choice, the risk can only be mitigated, not eliminated. The primary mitigation is to enhance the security and decentralization of the Guardian set itself. This requires ensuring each Guardian uses institutional-grade key security (e.g., HSMs), increasing the size and diversity of the Guardian set to make collusion more difficult (e.g., moving from 2-of-3 to a larger set like 7-of-13), and implementing robust, real-time public monitoring of all Guardian-signed messages to immediately detect any anomalous or unauthorized activity. Furthermore, the identities of the Guardian operators should be public and reputable to create social accountability.

low Issues | 2 findings

Resolved

#1 low Issue
Pause Logic on Solana Contradicts "IncomingOnly" Specification
zera_bridge_token/src/lib.rs
L268-419
L421-589
L591-1031
Description

There is a direct contradiction between the documented behavior of the bridge's pause functionality and its implementation for all incoming transactions on Solana. The README specifies that a Level 1 pause is "IncomingOnly," meaning it should block incoming transfers. The code for all three incoming functions (release_sol, release_spl, and mint_wrapped) correctly implements this by failing if the pause level is 1 or greater (e.g., check_pause(&router_cfg_data, 1)? on line 285). However, this is the opposite of the Zera-side implementation, which also blocks incoming transfers at Level 1. This means the term "IncomingOnly" is meaningless. More importantly, this creates a situation where if the Zera side were fixed to correctly allow incoming transfers at Level 1, the Solana side would still block them, leading to continued operational confusion.

Comments

The desired behavior for a Level 1 pause must be decided and implemented consistently across both chains. If Level 1 is truly "IncomingOnly," then the checks in these Solana functions are correct, but the checks in the Zera-side functions are wrong. If Level 1 is meant to be something else, the code on both chains and the documentation must be updated. This inconsistency in security-critical logic between the two chains is a significant risk.

Resolved

#2 low Issue
Permanent Fund Loss Due to Unvalidated Recipient Account Type
zera_bridge_token/src/lib.rs
L268-420
L421-589
L591-1030
Description

All three "incoming" functions that deliver assets to a user on Solana (release_sol, release_spl, mint_wrapped) fail to validate the type of the recipient account. The VAA from the Guardians contains the destination recipient address, which is passed into these functions. The code proceeds to transfer tokens (or SOL) to this address (or its associated token account) without verifying that the recipient is a user-controlled wallet (an Externally Owned Account). This allows for a scenario where a user on the source chain (Zera) provides the address of a Solana smart contract or program as their destination. The transaction on the source chain will succeed, but the transaction on Solana, while also succeeding, will transfer the assets to an account that the user cannot control. For example, if tokens are sent to an ATA owned by a program, only that program can move the funds, meaning they are permanently locked and lost to the user.

Comments

All three incoming functions must be modified to verify the nature of the recipient account. Before any transfer or minting occurs, the function must check that the owner of the recipient account is the official System Program. This is the standard, on-chain method for confirming that an account is a user-controlled wallet and not another smart contract. A require!(ctx.accounts.recipient.owner == &System::id(), ...) check should be added. This would cause the transaction to fail safely if the destination is an invalid account type, allowing the Guardians' VAA to be re-submitted with a correct address and preventing this form of irreversible fund loss.