Security

Security & Audits

Topaz is built with security as a primary design constraint. Core contracts inherit extensively deployed Aerodrome, Velodrome and Uniswap lineage with substantial production history and upstream audit coverage, and Shieldify Security independently reviewed what Topaz changed and added on top of that baseline, ahead of mainnet.

xTOPAZ and multichain security scope

Audit scope. The linked Shieldify report covers the earlier BNB Topaz contracts. It does not cover the later xTOPAZ vault, system gauge, coordinator, OFT bridge, composers, spoke voting vault or CL Zap. These are deployed separately; consult each release's own review records. Local fork signatures cover parts of the xTOPAZ and liquidity lifecycles, but do not establish mainnet delivery or a complete wallet lifecycle. Contract addresses.

The BNB core is retained. Reusing Voter, reward, gauge and pool code on spokes reduces new code, but does not validate deployment wiring, bridge configuration or the combined system. A chain listing, quote or successful approval simulation is not evidence that the whole transaction journey is live or validated.

Additional risks and controls

Backing and redemption: xTOPAZ represents permanently locked TOPAZ. Its market price can diverge from backing value; redemption returns a permanent NFT and can be blocked by vote state, pauses, split permissions or a rebase backlog.
NFT conversion: wrapping burns the source NFT. Resolve fees, incentives and relay-related rewards before giving up that ID. The router’s operator approval covers all of the owner’s veTOPAZ NFTs.
Bridge delivery: LayerZero endpoints, message verification and execution, chain finality and route configuration are dependencies. Source confirmation does not establish destination receipt. Pauses and capacity limits can delay delivery.
Spoke custody: voting stakes have withdrawal dates. Adding funds can extend the whole position’s date; voting restrictions can also delay closing it.
Administration: vault entry and redemption have separate pause controls. Bridge administrators configure peers, verification settings and limits. The coordinator can withdraw held budget shares; receivers and composers have defined rescue powers. A non-upgradeable core does not remove these authorities.
Data: snapshots, prices and exchange rates can differ in age across chains. A missing price or receipt must not be turned into a zero balance or a successful outcome.

See Protocol Governance for the extended role map, Bridge xTOPAZ for delivery checks and network availability before interacting.

Shieldify Security Audit

Audit Report

Topaz DEX Security Review

Reviewed by Shieldify Security · published on their public audits portfolio

Read Report ↗

Shieldify reviewed what Topaz changes and adds relative to the Aerodrome codebase it forks. That baseline has years of production history and already carries its own audit history, so the engagement was scoped to where Topaz-specific risk actually lives rather than re-deriving known-good code. The full PDF is hosted on Shieldify's GitHub for independent verification.

⚠What this audit does not cover

A differential review is not a full protocol audit. The inherited Aerodrome / Velodrome code was treated as a known-good baseline and was not re-examined line by line as part of this engagement — its assurance comes from its own audit history and production track record, not from this report. Read the PDF for the exact scope, and treat the protocol as carrying smart-contract risk regardless.

Every deployed contract is listed on the Contracts page with explorer links for each network, so the source can be cross-checked on-chain against both the report and the upstream codebase.

Contract architecture

Core contracts inherit from OpenZeppelin's audited implementations where possible. Each external function is guarded by the appropriate pattern:

✓Reentrancy protection on the fund-moving entry points: OpenZeppelin nonReentrant across the v2 pools, gauges, rewards contracts and VotingEscrow, and the lock mutex on Slipstream pools.
✓Emergency controls are subsystem-specific rather than one protocol-wide switch. The v2 PoolFactory exposes a single factory-wide swap pause covering its v2 pools; Slipstream pools have no pause path; gauges are killed and revived individually through the Voter. No emergency control transfers or seizes user balances, and v2 LP withdrawal stays open while swaps are paused.
✓Access control on privileged setters (fee manager, emergency council, pauser, vetoer) via OpenZeppelin Ownable / role patterns.
✓Arithmetic safety differs by generation: the Solidity 0.8.19 contracts (v2 core, gauges, governance) rely on built-in checked arithmetic, with unchecked blocks only where overflow is mathematically impossible. The Slipstream core retains its audited Solidity 0.7.6 lineage and uses explicit LowGasSafeMath and SafeCast libraries instead.
✓EIP-2771 trusted forwarder support for meta-transactions, isolated to the Forwarder contract.
✓Key administrative and economic state changes emit events for off-chain monitoring and analytics.

Immutability and upgradability

The existing BNB core takes a specific stance on immutability vs. evolution: core contracts and deployed factories are immutable, the protocol extends by approving new factory implementations through FactoryRegistry, and migration is opt-in by users.

✓Core: Pool, Gauge, VotingEscrow, Voter, Minter, RewardsDistributor, and the Governors are not upgradable. No admin proxy. The code on BscScan today is the code forever.
✓Factories: FactoryRegistry can approve or remove factory implementations for future pools, gauges and rewards contracts. Approving a new implementation does not modify existing deployed factories or pools — PoolFactory, CLFactory, GaugeFactory, CLGaugeFactory, VotingRewardsFactory and ManagedRewardsFactory sit behind no proxy and cannot be upgraded in place.
✓Migration: when a new factory is approved, existing pools and positions are not forced to migrate. LPs and voters opt in by depositing into the new generation if they choose.

Admin controls

The BNB core administrative roles currently sit with the protocol multisig and its signers, with the governance contracts deployed alongside them as on-chain governance activates. What those roles can reach is bounded by immutable code rather than by policy — these limits are enforced by the contracts themselves and cannot be lifted by any key:

✓No key can mint TOPAZ outside the emission curve. The schedule is fixed in the Minter and the team rate is hard-capped at 5%.
Core roles do not provide an arbitrary transfer of user LP positions, veTOPAZ NFTs or wallet balances. Emergency controls can restrict actions, and the multichain extension has additional pause, budget-custody and rescue powers described above.
✓Swap fees cannot be raised without limit. v2 fees and Slipstream base / custom fees are hard-capped at 3% by immutable constants, not settings. A Slipstream pool running the dynamic-fee module can charge more than its base fee while spot diverges from TWAP, bounded by that pool's configured feeCap — which the module itself will not let anyone set above an immutable 5%.
✓Core contracts cannot be upgraded. Pool, Gauge, VotingEscrow, Voter, Minter, RewardsDistributor and the Governors have no admin proxy.
✓Within those bounds, admin roles can kill or revive gauges, use subsystem-specific emergency controls, configure fees within their contract-enforced caps, whitelist tokens for gauge creation, and approve new factory implementations.

The full admin role map is documented in Protocol Governance. Current role holders are visible on-chain via the verified contracts on the Contracts page.

Risk disclosure

DeFi carries inherent risks. The most relevant to Topaz:

Smart-contract risk: even after audit, latent bugs are possible. Use the protocol at your own risk.
Impermanent loss: LP positions can lose value relative to holding. Concentrated ranges amplify both fee yield and IL. See the IL primer.
Governance risk: parameters within governed ranges can change. The bounds themselves (emission caps, fee caps, lock periods) are immutable. See Protocol Governance for what governance can and can't touch.
Oracle risk: TWAP prices are manipulation-resistant but not perfect. Oracle-dependent integrations should use appropriate cardinality and window lengths. See Oracles & TWAP.
Regulatory risk: DeFi protocols are not regulated as financial intermediaries in most jurisdictions; your local rules may apply.
Operational risk: phishing sites, fake support, malicious approvals. Always verify URLs and never sign transactions you don't understand.

Participants should conduct their own research and never commit more than they can afford to lose.

Responsible disclosure

If you discover a vulnerability in any deployed Topaz contract, please report it privately before disclosing publicly. Reach out via Telegram to coordinate a private channel. Active bug-bounty terms are published separately and updated as the program evolves.

⚠Don't post exploits publicly

Tweeting an unpatched exploit, or attempting to demonstrate it on mainnet, puts real user funds at risk. Coordinate disclosure first; we'll work fast.