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.

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 verified BscScan links, 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 protocol 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

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%.
✓No key can move, seize, or freeze user funds. LP positions, veTOPAZ NFTs, and token balances are out of reach of every role.
✓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.