Building a MetaDEX like Thena | ve(3,3) DEX Architecture

If you’re working on ve(3,3) DEX development, or researching how MetaDEXes work, how they manage liquidity and incentives, this post is for you.

We’ll walk through the mechanics, the voting system, emissions, economic flows, and the contract architecture behind ve(3,3) implementations.

‍

Make sure to follow us on X to stay updated on our upcoming technical deep dives on protocol design and architecture 🌚

The context. Why we’re even talking about ve(3,3)

DEXs often struggle to keep liquidity deep and consistent over time. Founders venturing into DEX development face similar challenges:

• Liquidity leaves when rewards drop: Many AMMs reward early liquidity providers with high token emissions. Once these rewards taper, users often pull their capital, leaving pools thin and volatile.
• Short-term capital dominates: Some participants chase the highest yield across protocols rather than supporting the DEX long-term. This “liquidity mercenary” behavior makes growth unpredictable.
• Inefficient capital use: Standard AMMs can lock liquidity in pools where it isn’t fully productive, limiting the protocol’s ability to generate fees or fund incentives.

Liquidity challenges in DEXs are not a new problem. Projects keep exploring approaches from intents, liquidity aggregation, to incentive structures. Today, we’re going to cover the ve(3,3) model, how it works in DEXs from workflow to architecture and contracts.

What is ve(3,3)?

ve(3,3) is an incentives model used in crypto DEXs that combines Curve Finance’s vote-escrow (ve) mechanics with OlympusDAO’s (3,3) game theory framework. Users lock the native token to gain voting power that directs how project-token emissions are allocated to pool gauges as rewards for liquidity provision. The (3,3) layer models stake/bond/sell choices, shaping incentives for LPs and voters.

What “ve” Means

The “ve” part comes from Curve’s vote-escrow model (veCRV). Users lock a certain amount of CRV for a chosen period to receive veTokens. Voting power is highest right after locking and decreases linearly as the lock approaches expiration.

Key veTokens utility

ve voting determines how protocol emissions are distributed across liquidity pools, by influencing:

• Governance voting — deciding on protocol proposals
• Boosting rewards — increasing yields in selected liquidity pools
• Directing emissions — influencing how token rewards are distributed

Manipulation Risks

The ve system also created room for manipulation and caused Curve Wars. Large holders or aggregators like Convex Finance concentrated veTokens, controlling how rewards were distributed across pools. Smaller participants faced a Catch-22: to maximize rewards, they needed veTokens, but when most veTokens were controlled by whales, their influence and share of emissions became minimal.

How ve model works in ve(3,3)

Andre Cronje adapted Curve’s vote-escrow model for Solidly Exchange to create ve(3,3), keeping the idea of time-locked veTokens while adding key improvements.

• Dynamic emissions: Weekly token emissions decrease as more tokens are locked.
• veToken holders protected: Holders’ balances grow proportionally to emissions, avoiding dilution.
• NFT locks: Each lock is a unique NFT, allowing multiple locks per address, cumulative voting power, and potential secondary market use.

What (3,3) Means

The “3,3” in ve(3,3) comes from a game-theory logic first explored in OlympusDAO’s staking experiments. Think of it as a simple framework to illustrate how users’ choices—stake, bond, or sell could affect both their rewards and the protocol’s health.

How the model works:

• (3,3) — Stake/Stake: Both users lock tokens, maximizing rewards and reducing circulating supply.
• (3,1) / (1,3) — Stake/Bond combinations: One stakes while the other bonds. Liquidity improves, and both participants gain some rewards.
• (1,-1) / (-1,1) — Stake/Sell or Bond/Sell: Selling undermines rewards and reduces benefits for others.
• (-3,-3) — Sell/Sell: Worst case. Tokens flood the market, rewards collapse, and the protocol suffers.

This model is based on the assumption that users act according to their best financial interest, prioritizing long-term gains and rational cooperation. In reality, several problems arose in OlympusDAO and its forks:

• Short-term profit-seeking: Users often prioritized immediate rewards over protocol stability.
• Panic selling: Market volatility and decreased APYs triggered mass sell-offs.
• Coordination failure: The protocol relied on continuous cooperative behavior, which is difficult to sustain in practice.

In ve(3,3), this game-theory logic is still applied: users’ actions interact with veTokens to influence emissions and reward distribution. The design encourages cooperation (staking/locking) while making selling less attractive. Though, like OlympusDAO, outcomes still depend on participants’ choices and behavior patterns.

So, how veTokens and game theory work in ve3,3 DEXes?

As we already mentioned a ve(3,3) is a tokenomics model used in crypto DEXs that combines Curve Finance’s vote-escrow (ve) mechanics with OlympusDAO’s (3,3) game theory framework. These two components work together to create a self-reinforcing economy for liquidity providers and token holders. In a ve(3,3) DEX, liquidity provision is combined with staking and voting to maximize rewards. Here’s how it works:

1. Liquidity provision: LPs provide liquidity as usual, but instead of earning a share of trading fees, they stake their LP tokens in gauges. This allows them to receive weekly token emissions as rewards.
2. Voting with locked tokens: Users lock their tokens in a vote-escrow (ve) contract to gain voting power. They then use this power to vote on how token emissions are distributed across different pool gauges.
3. Earning from participation: Voters earn a share of trading fees, token emissions, and external bribes for the pools they support, proportionally to the votes they cast.

This creates a rewards loop: provide liquidity → earn project tokens → lock these tokens to gain voting power → influence emissions → earn more rewards for voting and liquidity provision.

Now that we’ve covered the core concepts of ve tokenomics, let’s dive into how it all works on a lower level.

Core Components and Workflow in ve(3,3) DEXs

If you’re looking at a ve(3,3) DEX for the first time, it can feel like a lot is happening at once. Let’s break it down into the building blocks and then walk through how they work together.

Core Components

We recently forked Thena for one of our projects, so we’ll use it as an example here. That doesn’t mean it’s the only perfect model nor an ideal codebase to fork — we actually ran into bugs in the contracts that needed fixing. But since we’ve actively worked with it, it’s a good reference for how a ve(3,3) DEX works.

Liquidity layer

A ve(3,3) DEX is a DEX in the first place, so liquidity provisioning is where it starts. Without liquidity, trades won’t happen and the system can’t function. Different assets and LP strategies require different mechanics, so many ve(3,3) DEXs have multiple pool types. We covered the core market making models in DEX development in a separate deep dive, we’ll keep it high-level here and focus on what matters for this workflow.

vAMM (Constant-Product Market Maker)

vAMM handles volatile assets using the x · y = k formula. Every trade shifts reserves and updates prices along the curve automatically. It’s straightforward and predictable, which makes it reliable for pairs that don’t move together closely.

sAMM (Stable-Asset Market Maker)

sAMM is built for assets that stay close to a defined peg like stablecoins, LSTs, and similar pairs. It mixes constant-product and constant-sum curves to keep slippage low around that peg, while still supporting trades that move a bit beyond it.

In Thena, sAMM and vAMM pools live in a single factory. You pick the type, deposit the token pair, and receive ERC20 LP tokens. From there, the pool runs according to its mechanics and plugs into the ve(3,3) system.

CLMM (Concentrated Liquidity Market Maker)

CLMM allows LPs to concentrate liquidity within chosen price ranges rather than along the full curve. It operates on ticks, ranges, and fee tiers. Positions are NFTs and stop generating fees when the price leaves the range, so LPs need to monitor and adjust their positions.

ALMs (Automated Liquidity Managers)

ALMs like ICHI and Gamma let you provide liquidity with just one token. You deposit into the ALM vault, and the ALM handles all concentrated liquidity positions on your behalf: opening, adjusting, and rebalancing ranges automatically. It then issues ERC20 vault tokens representing your share of the vault, same as LP tokens. Swap fees collected by the ALM are forwarded to the ve(3,3) contracts for distribution to voters, which we cover in the workflow section.

Trading Layer

We all know how trading interfaces work. In a ve(3,3) DEX, swap fees provide the incentive for voters: fees generated by LPs flow into the system and are distributed to participants who vote on gauges. This creates the core economic feedback loop, where voting power and veNFTs determine who captures these rewards.

Since a typical ve(3,3) implementation includes both AMM and CLMM pools, trades may move through several pool types. A routing module checks available pools and picks the path with the best price. The outcome of that path determines two things we need for the later sections:

1. How much fee each pool produces.
2. Which pools accumulate value that later enters the ve(3,3) reward logic.

AMM Pools

• Swap fees accumulated by Gauges (staked LPs) go to voters.
• Unstaked positions earn swap fees directly, like in any other DEX.

CLMM Pools and ALMs

• ALM-managed positions: fees are accumulated by the vault and forwarded into the ve(3,3) system, where they are distributed to voters.
• Manual ERC721 CL positions: independent from ve(3,3); they earn fees directly.

Swap Fees Distribution Tranches

The exact split depends on the project. In the system we worked on, fees were divided into:

• xNFT stakers (temporary for the first 12 epochs)
• Providers (Algebra, ICHI)
• Treasury
• Voters or manual LPs (remaining portion)

Gauges

Gauges are the staking component that links liquidity providers to the ve(3,3) system. Liquidity providers deposit LP tokens into a gauge and earn project-token emissions. The emissions allocated to each gauge are determined by weekly ve(3,3) voting results. Swap fees generated by LPs are distributed among voters who supported that gauge.

Voting layer

The voting layer is the set of components that coordinates veNFTs, votes, and bribes to manage protocol incentives. It determines how project token emissions are allocated to gauges and how swap fees are distributed to voters. It also tracks vote weights, supports veNFT operations such as merging or splitting, and processes both internal and external bribes that influence voter behavior.

Voting Escrow (veNFTs)

Users lock protocol tokens in the VotingEscrow contract for a chosen period, up to 2 years, and receive veNFTs representing their voting power. Voting power decreases linearly as the lock approaches its end. veNFTs can be merged, split, or topped up with additional tokens, and their lock period can be extended, giving users full control over their voting influence and reward claims.

Voting System

The voting system is the component where veNFT holders allocate their voting power to gauges, determining how project-token emissions and swap fees are distributed. Voting power is proportional to the veNFT’s locked amount and remaining lock duration.

Voters can split the voting power of a single veNFT across multiple gauges, and they can reset and reallocate votes each week, adjusting or repeating their previous allocation. Voters earn Bribes and Rebase rewards  a portion of emissions distributed to veNFT holders) and bribes for participating in voting).

Rewards are distributed based on votes cast by veNFT holders. The system calculates rewards weekly and allows users to claim them for one or multiple veNFTs.

Bribes

Bribes are core incentives for voting:

• Internal bribes: swap fees collected by LPs in gauges, distributed to voters who supported the gauge.
• External bribes: additional rewards from third parties to influence voting outcomes.

Emissions Layer

The emissions layer defines how much new Tokens enter the system each week and how it’s allocated. Since ve(3,3) DEXs run on weekly epochs, emissions, decay, and distribution all update once per epoch. This layer powers liquidity incentives and rebase rewards for veToken holders.

Emission Schedule

Each epoch, the protocol counts the new weekly emission amount.
Most ve(3,3) DEXs use a decay-based schedule, where emissions decrease over time. The formula varies by protocol, but the workflow is the same:

• start with last week’s emission amount
• apply the project’s decay rule
• (optionally) apply tail emissions based on circulating supply
• finalize the weekly emission value for the new epoch

Emission Distribution

Once the weekly amount is calculated, it is split across several tranches:

• Gauge incentives:
  Distributed to gauges based on veToken voting results for the epoch.
• Rebase to veToken holders:
  A portion of emissions goes directly to voters as a rebase, increasing their locked Token balance.
• Optional tranches (project-specific):
  Some DEXs add extra destinations such as referral rewards or NFT staking rewards, team, treasury etc.

Epochs

When covering gauges, voting and emissions, we were consistently mentioning weekly updates and that everything works on a weekly basis.
ve(3,3) DEXs operate on epochs that last one week. Each epoch, veNFT votes are counted to determine gauge emissions, reward calculations are finalized, and swap fees from gauges are distributed to voters. All user actions, including vote resets, reward claims, and emission updates, occur on this weekly cycle, defining the system’s update rhythm.

ve(3,3) DEX Mechanics

Okay, so by this point we’ve covered the core components and we now know that there’re several layers in the system that take part in the whole ve(3,3) mechanics from trading to LPs voting to token emissions. But how do the funds move in the system? Let’s go through the very basic workflow.

From here we’ll cover the workflow for concentrated-liquidity pools. The mechanics mirror AMM workflows but add one layer: Automated Liquidity Managers (ALMs) that open and manage CL positions and route fees into the ve(3,3) system.

In short, high-level flow is:

1. LPs deposit into an ALM — ALM opens and manages CL positions and issues an ERC20 LP token to the depositor.
2. LPs stake ERC20 LP tokens into Gauges to become eligible for emissions.
3. CL Core processes trades against concentrated-liquidity positions.
4. FeesVaults collect swap fees (ALM forwards collected fees to the vaults).
5. Gauges distribute project-token rewards to stakers according to gauge weights.
6. Voting Escrow locks tokens and issues an NFT-style veToken that represents voting power.
7. Users vote on pools; voters receive:
   
   • internal bribes (portion of swap fees routed via FeesVaults),
   • external bribes (optional, supplied by third parties),
   • rebase rewards (the ve-token share of weekly emissions).

Workflow Explained Step by Step

To make the high-level mechanics concrete, let’s follow a single participant, Alice, as she engages with the system. Let’s look at the diagram to track how her actions trigger changes across the system and how rewards are routed.

Step 1 — Alice Provides Liquidity

Alice deposits liquidity into a concentrated liquidity pool (CL core) via automated liquidity manager (ALM).
She receives ERC-20 LP tokens that represent her position.

These LP tokens define her next options:

• stake them into a gauge
• keep them unstaked
• withdraw liquidity later

Let’s say she chooses to stake her LP tokens in a gauge

Step 2 — ALM Manages Alice’s Liquidity

The protocol’s ALM manages the underlying CL position. It handles:

• selecting price ranges
• adjusting ranges over time
• collecting swap fees

Alice doesn’t interact with any of this, ALM abstracts it.

Whenever ALM collects swap fees from the position, it forwards them into the FeesVaults contract.

Step 3 — Fees Move Into FeesVaults

Each trade through the CL core generates swap fees.
The CL core transfers those fees to ALM-managed positions, and ALM routes them to FeesVaults.

At this point, two separate reward streams are forming:

• LP rewards → token emissions distributed by gauges
• Swap fees + bribe rewards → from the voting side

Alice can tap into both — but only if she also participates as a voter

Step 4 — Alice Locks Tokens to Get Voting Power

To influence how much her pool’s gauge receives, Alice locks the protocol’s token in Voting Escrow.

Locking gives her:

• a veNFT
• voting power proportional to lock time and amount

Voting power allows to vote for the gauges to determine how weekly emissions are directed across all gauges in the system.

Step 5 — Alice Votes for Her Pool’s Gauge

Alice votes for the gauge tied to the pool where she provided liquidity.

As a result:

• that gauge receives a higher emission weight
• more rewards flow to LPs staking in that gauge
• Alice’s own gauge rewards increase

After voting finishes, Voting Escrow passes weekly vote totals to Gauges.

Step 6 — Gauges Update the Reward Rates

Gauges read the aggregated voting results and update emission rates for the new epoch.

Since Alice staked her LP tokens in the gauge, she now receives:

• project token emissions

This covers the LP side of ve(3,3).

Now, let’s see what’s happening on the voter's side.

Step 7 — Bribes and Voter Rewards

After voting, Alice receives rewards based on the voting power she allocated. These include internal bribes, external bribes, and rebase rewards.

Internal bribes

• Swap fees collected by the pool she voted for.
• Alice gets a share proportional to the voting power she used.

External bribes

• Additional rewards added to the gauge by the protocol or third parties to incentivize votes.
• Alice receives her share based on her voting power.

Rebase rewards

• A portion of weekly token emissions allocated to active voters.
• These rewards are credited to the veNFT Alice used to vote.

Alice’s Full Revenue Flow

By providing liquidity and locking tokens to vote, Alice can now earn four types of rewards:

1. Gauge emissions
2. Rebase rewards
3. Swap fees (internal bribes)
4. External bribes

‍

MetaDEX Technical Implementation

Like any DEX development, a ve(3,3) implementation has several components you need to consider: smart contracts, backend services, frontend logic and interfaces as well as third party providers integrations. Contracts enforce liquidity, staking, gauge voting, and emissions. Backend exposes API endpoints for LP positions, gauge weights, and emissions history. Frontend lets users interact with pools, stake LP tokens, vote with veNFTs, and claim rewards. Providers like Algebra or ALMs handle pool creation and automated CL management.

If you want to see how all of these components come together in a life product, check out our SwapX MetaDEX development case study. It shows multi-AMM integration, automated liquidity via ICHI, NFT staking, and custom emissions logic across 30+ contracts with backend and frontend integration: Read the case study

Smart Contract Architecture

Today, our core focus is on the contracts layer. We recently built a fork of Thena, and we’ll use it as a reference for this overview. We’ll walk only through the core contracts where the ve(3,3) logic lives, leaving v2 AMM DEX contracts aside; they follow similar patterns with concentrated liquidity, so the concepts carry over.

Thena resources:

• Thena codebase: https://github.com/ThenafiBNB/THENA-Contracts
• Thena documentation: https://docs.thena.fi/thena/

Let’s look at the diagram and walk through the core contracts to see how token emissions, staking, voting, and reward distributions are managed.

Project Token Contract

Project Token is a standard ERC20 token, with the predefined initial mint amount, based on the tokenomics specifications. The minting process is managed by the MinterUpgradeable contract.

Core variables:

• bool public initialMinted — tracks if the initial mint has been executed.
• address public minter — address allowed to mint tokens (set to MinterUpgradeable).

Key functions:

• setMinter(address _minter) — updates the minter address post-deployment.
• initialMint(address _recipient) — one-time mint of the first initial supply.
• mint(address account, uint amount) — regular minting directed by the minter contract.

MinterUpgradeable

This upgradeable contract handles token emissions on a weekly basis and distributes them across four tranches: team/masterchef, veNFT holders (rebase), Gauge pools, and referral program.

Emission logic:

• Base weekly emission: the starting point for calculating emissions, based on business requirements.
• Weekly decay: weekly = weekly * 99%.
• Rebase and emission percentages are adjustable by the team.

Core variables:

• EMISSION, TAIL_EMISSION — governs emission percentages.
• REBASEMAX, REBASE_MIN, REBASE_STEP, currentRebaseRate — control veToken holder rewards.
• teamRate, referralRate, surplusTokens — allocation parameters.
• weekly, active_period — track current emission and last update.

Key functions:

• update_period() — mints tokens and distributes according to the emission schedule.
• Governance and team functions allow adjustment of emission, rebase, referral, and reward settings.

VotingEscrow (veNFT)

veNFT tokens are ERC721 NFTs representing locked project tokens positions with linear vote decay. Users lock tokens for up to 2 years in exchange for veNFT, which powers Gauge voting and bribes. veNFT tokens can be merged or split, enabling flexible voting strategies.

Core structures:

• Point — tracks vote weight, slope (decay), timestamp, and block.
• LockedBalance — amount locked and lock end timestamp.

Key functionalities:

• create_lock, increase_amount, increase_unlock_time — deposit and adjust locks.
• merge/split — combine or divide veNFT tokens.
• delegate and delegateBySig — delegate voting power.
• Epoch-based tracking allows precise calculation of voting weights over time.

RewardsDistributor

A contract for distributing tokens to veNFT holders. Each week, the update_period function must be called on the MinterUpgradeable contract to mint new tokens. A portion of these tokens is sent to the RewardsDistributor contract, which then calls checkpoint_token (iterating over weeks to calculate the number of tokens to distribute each week) and checkpoint_total_supply (iterating over weeks to calculate the total voting weight, determining how many tokens each holder is entitled to).

Core operations:

• checkpoint_token() — calculates weekly rewards for all veNFT holders.
• checkpoint_total_supply() — tracks total voting power per week.
• claim/claim_many — allows users to withdraw accumulated rewards.

VoterV3

A contract that allows veNFT holders to vote on Gauge pools. Voting determines the amount of token rewards allocated to each Gauge pool. Additionally, holders who voted for a specific pool receive rewards in the form of swap fees from that pool (through the Bribes contract). The contract operates in epochs, aligned with MinterUpgradeable.

Key points:

• Pools and Gauges are mapped for voting and reward tracking.
• Votes are epoch-based; only the latest vote is stored per tokenId.
• Functions exist for distributing rewards (distribute, distributeAll) and claiming fees (claimFees, claimBribes).

GaugeV2_CL

A staking contract where users deposit Ichi LP tokens (wrapped concentrated liquidity LPs) to earn token rewards.

Core features:

• Epoch-based reward distribution (7-day periods).
• Tracks individual rewards and total staked balances.
• Emergency mode disables deposits and withdrawals for safety.

Reward flow:

1. MinterUpgradeable mints project tokens → VoterV3.
2. VoterV3 allocates these tokens to Gauges based on votes.
3. GaugeV2_CL distributes rewards to stakers per epoch.

Algebra Integral

DEX engine used as the core for Concentrated Liquidity (CL) pools. Provides all core CLMM logic needed for pool operation. Additional features can be added through Plugins. Swap fees from pools are collected in AlgebraCommunityVault and are used for fee distribution calculations.

• Core repository: Algebra
• SDK and tooling: Integral SDK

ICHI Vaults

ICHI provides single-sided concentrated liquidity management on AMMs.

• Deposits: Users deposit a single token; the vault mints LP tokens representing their position. No paired-token requirement.
• Liquidity Management: On-chain algorithm tracks deposited token amounts and inventory. Liquidity is repositioned only when pool composition deviates from the target ratio.
• Rebalancing: Adjusts liquidity ranges without unnecessary swaps, minimizing asset exposure and transaction costs. Fully on-chain.
• Yield Accounting: Trading fees collected from the active liquidity range are tracked and attributed to LP token holders.
• Withdrawals: LP tokens can be redeemed for underlying assets at any time.

Docs & Contracts:

• ICHI Docs
• Contract Addresses

CLFeesVault

Collects trading fees from Ichi vaults and distributes them to internal bribes.

Core role:

• Collects and distributes fees per gauge.
• Admin can configure pool, voter, and recover ERC20 tokens.

Key variables:

• voter — VoterV3 contract address.
• pool — target Ichi pool.
• permissionsRegistry — PermissionRegistry contract address.

Core functions:

• claimFees() — collect and distribute fees from pool to internal bribe.
• setVoter, setPermissionRegistry, setPool — configuration by admin.
• emergencyRecoverERC20 — recover ERC20 tokens to team address.

Events:

• Fees(...) — logs fee amounts per token, pool, and timestamp.

Bribe

A single contract with two use cases:

• Internal: distributes a portion of collected trading fees to veNFT holders who voted via VoterV3.
• External: distributes rewards from an external address in one of the supported tokens (manually allocated; for example, one pool’s external bribe rewards were sent from a separate Gnosis wallet).

Core role:

• Track epoch-based rewards for veSWPx voters.
• Deposit/withdraw votes and claim rewards.

Key variables:

• rewardData — mapping for token rewards per epoch.
• rewardTokens / isRewardToken — supported reward tokens.
• voter, bribeFactory, ve, minter, owner — contract addresses.
• _totalSupply — total votes per epoch.

Core functions:

• View: balanceOf, balanceOfAt, earned, totalSupplyAt, getEpochStart, getNextEpochStart.
• Voter: _deposit, _withdraw, getRewardForOwner, getRewardForAddress.
• Admin: addReward, addRewards, recoverERC20AndUpdateData, emergencyRecoverERC20.
• Public: notifyRewardAmount, getReward.

Events:

• RewardAdded, Staked, Withdrawn, RewardPaid, Recovered.

Business Requirements Driven Layer

Okay, by now it may seem we’ve covered the core ve(3,3) contracts. There’s another layer worth looking at: supporting early investors. Getting them involved after a fundraiser can be complicated, especially if you want them engaged over time.

The project we worked on recently ran a fundraise through a limited NFT collection, following Thena’s approach, keeping these NFTs integrated with the protocol. As part of this integration, the protocol tracks users who bought NFTs as original minters, allowing them to claim token airdrops (where claim is split between vesting and veNFTs), stake their NFTs to earn swap fees in project tokens, and receive royalties from secondary NFT sales.

Contracts and implementation

xNFT Collection

Limited NFT collection (3,000 max) with royalties and optional trading fee rewards. Metadata is stored via URI.

Core Variables

• MAX_SUPPLY, NFT_PRICE, SALE_START_TIMESTAMP: define supply, price, and mint start.
• MAX_RESERVE, reservedAmount: track owner-reserved NFTs.
• root: Merkle root for whitelist verification.
• multiSig: address for collected funds.

Important Functions

• mint(amount, proof): public mint for whitelisted users after sale start.
• reserveNFTs(to, amount): owner mints reserved NFTs.
• withdraw(): send funds to multiSig.

Royalties

Distributes rewards to original NFT minters from secondary sales.

Key Variables

• feesPerEpoch, totalSupply, reservedAmounts: track rewards per epoch.
• depositors: allowed to deposit rewards.

Important Functions

• deposit(amount): deposit rewards to distribute to minters.
• claim(user): claim earned rewards.

FeeConverter

Converts collected trading fees into the reward token and sends them to the staking contract.

Key Points

• Receives fees in various tokens and converts them to the reward token.
• Sends converted rewards to the staking contract.
• Controlled by owner and keeper roles.

Important Functions

• swap(): convert all fees and send to staking contract.
• setPathToToken(token, path): configure conversion routes.

NFTSalesSplitter

Automates distribution of collected fees to Royalties and FeeConverter.

Key Points

• converterFee and royaltiesFee define split ratios.
• Integrates with FeeConverter and Royalties.

Important Functions

• split(): triggers fee collection, conversion, and distribution.

MasterChef (NFT Staking)

Stakes NFTs for dual rewards: main (from FeeConverter) and extra (minter bonus). Extra rewards are split between Vesting and VotingEscrow.

Key Points

• Tracks staked NFTs and reward debt per user.
• Weekly reward distribution.
• veShare determines a portion of extra rewards to VotingEscrow.

Important Functions

• deposit(tokenIds): stake NFTs.
• withdraw(tokenIds): unstake NFTs.
• harvest() / harvestExtra(): claim main and extra rewards.

AirdropClaim + MerkleTree

Primary token distribution for partner users or original minters. Supports vesting and VotingEscrow.

Key Points

• Uses Merkle proofs to validate claims.
• Locked portion goes to VotingEscrow, remainder to vesting.

Important Functions

• claim(to, amount, proof): claim tokens via verified Merkle proof.

MerkleTreeNFT

Handles primary reward distribution for original NFT minters. Works with AirdropClaim.

Key Points

• Stores Merkle root and validates claims.
• Maps NFT minters to claimable rewards.

Important Functions

• claim(tokenId, amount, proof): distribute tokens to original minters.

We’ve now covered the key smart contracts that make a ve(3,3) DEX tick. Hopefully, that has given you a clear picture of how everything interacts under the hood. Next, let’s focus on what you need to keep in mind when building a ve(3,3) DEX.

Performance Considerations

When building or forking a ve(3,3) DEX, there are several critical aspects that determine how well your protocol performs. Some points may seem basic, but they are essential for delivering a seamless experience:

Security Audits

Audits are mandatory. Even if you fork a project that has done audits and been live for years, safety isn’t guaranteed. We’ve all seen examples of audited projects that still faced incidents. In ve(3,3) systems, dozens of interconnected contracts interact. Any small modification, whether in reward calculation, gauge logic, or token emission, can introduce vulnerabilities.

Backend and Automation

Everything in ve(3,3) runs on epochs. Token emissions, fee claims, and reward distributions all happen periodically and epochs updates must be triggered externally.

Services like Gelato can handle this automation if they support your chain. Otherwise, a backend service is needed to manage this automation. Multicall contracts are often used to batch operations across different contracts from updating epochs, claiming fees, to triggering splits, into a single transaction.

Indexing On-Chain Events

Users expect to see numbers: TVL, trading volume, APRs, rewards they’ve earned and gauge allocations. That data has to come from somewhere. Depending on the chain, indexing solutions vary. Some chains make it easier to track events in real time, while others require more complex approaches. We covered different approaches to onchain data indexing in our recent post about Indexing blockchain data

Chain-Specific Limitations

Not all EVM-compatible chains behave the same. TPS, block gas limits, and other chain-specific constraints affect how epochs, emissions, and gauge distributions run.

ZK-rollup chains bring additional considerations: Poseidon counters or Merkle proof limits can affect epoch-dependent calculations or veToken distributions.

Wrapping Up

This is the end of our deep dive into ve(3,3) DEX mechanics.

If you’ve made it this far, thank you for reading! Don’t forget to follow us on X for more technical deep dives and protocol insights.

Today we’ve covered the core contracts, workflows, and incentive mechanisms, but as with any complex system, there’s always more to explore. Consider this a starter for understanding how ve(3,3) DEXes work under the hood.

Key Takeaways

What Is ve(3,3) in DEX Development?

ve(3,3) is an incentive model that links token locking, emissions, and governance to liquidity depth. It creates a feedback loop where voters direct rewards, LPs supply liquidity where it is most profitable, and the DEX can retain long-term liquidity instead of attracting short-term yield chasers.

How Does ve(3,3) Tokenomics Work?

ve(3,3) tokenomics ties emissions to locked positions (veNFTs), which decide where weekly incentives go. High-volume pools attract more votes, which generates deeper liquidity and stronger fee flows. This system helps stabilize emissions, reduce mercenary liquidity, and align long-term contributors with the protocol’s growth.

What Do You Need to Know About Decentralized Exchange Development for ve(3,3)?

A ve(3,3) DEX relies on a multi-contract architecture: an AMM for fee generation, a VotingEscrow for locking, gauges for reward routing, and a minter for controlled emissions. The coordination between these components determines liquidity efficiency, trading depth, and the sustainability of incentives.

How to Create a Decentralized Cryptocurrency Exchange Using ve(3,3)?

To build a DEX with a ve(3,3) system, founders need to align AMM fee flow, locking mechanics, gauge voting, emissions distribution, and token supply and distribution parameters. Successful deployments plan liquidity bootstrapping, partner incentives, vote routing, long-term emissions schedules, and community allocation before launch.

How Does ve(3,3) Tokenomics Work?

1. Provide Liquidity – LPs deposit assets into pools to earn rewards.
2. Stake LP Tokens in Gauges – LPs lock their pool tokens to become eligible for project-token emissions.
3. Lock Tokens for Voting Power – Users lock the native token in a veNFT to gain voting influence over gauge rewards.
4. Vote on Emission Allocation – Voting power determines how weekly token emissions are distributed across liquidity pools.
5. Earn Rewards – Participants receive multiple reward streams:
   
   • Gauge emissions – tokens distributed to staked LPs.
   • Rebase rewards – veToken holders earn a portion of weekly emissions.
   • Internal bribes – a share of swap fees routed via the system.
   • External bribes – optional rewards from third parties to influence votes.
6. Reinforce the Loop – Locked tokens → voting → higher gauge rewards → deeper

‍