Core concepts
What is x(3,3)?
To understand how x(3,3) works, we need to first understand the metaDEX:
Origins of metaDEX
The metaDEX model has remained largely unchanged since Andre Cronje's first deployment. Modern implementations like Aerodrome Finance have proven metaDEX can achieve massive scale and sustainable revenue, but they rely on artificial restrictions to maintain participation. x(3,3) represents a fundamental reimagining—instead of forcing compliance through locks, it creates organic incentives where users want to stay because the system rewards active participation and naturally concentrates value among those who contribute most. To understand metaDEX, we need to break down two key concepts:
Rebase
A core element of the metaDEX model was the rebasing of locked positions to prevent a user from being diluted by emissions, OHM (3,3). This anti-dilution mechanic for veTOKEN holders allowed them to maintain the same ownership without having to buy and lock more tokens.
Here is a crude visual representation of it in action:
xPHAR addresses dilution with a unique "xPHAR Burn", which acts both as dilution protection and additional yield. Instead of minting new tokens to locked positions, x(3,3) does two things:
- xPHAR stakers earn value from protocol fees and voting incentives.
- xPHAR allows holders to exit early, sacrificing their voting power. On minting of xPHAR, 50% of the PHAR is burned allowing for a real constriction on the token supply.
Vote Escrow (ve)
The second concept you should understand is vote escrow (ve) - a fundamental change to governance and on-chain voting systems that introduced time-weighted voting.
Instead of voting with token amount a, tokens are lockable in a VotingEscrow, now shown as veA, for a selectable locktime
Your vote is not only calculating total tokens held, but also the lock duration. Curve first introduced this in a 2020 whitepaper.
A visual representation can be seen below:
This system intentionally creates a risk vs. reward scenario. where more governance power is given to active participants continually extending their locks. x(3,3) has a similar decision matrix, but users do not have to lock tokens to participate.
metaDEX ➡ x(3,3)
metaDEX still has a fundamental design flaw: it relies on static commitment rather than dynamic value creation. Even successful implementations like Aerodrome require users to make upfront commitments to earn meaningful rewards, creating a system where participation is driven by obligation rather than ongoing value. x(3,3) flips this entirely—it rewards users based on their active contribution to protocol success, with exit flexibility that ensures only those who genuinely value the protocol remain engaged. This creates a self-selecting community of active participants rather than passive token holders who do not participate.
Now that you understand metaDEX, the question persists:
How does x(3,3) improve this?
xPHAR is where x(3,3) shines by creating a incentive system that responds to real user behavior. While traditional metaDEX models like Aerodrome create value through artificial scarcity and forced commitments, x(3,3) generates value through genuine user activity. When users exit, their value flows to remaining participants. This creates a dynamic ecosystem where rewards scale with protocol success and ownership naturally concentrates among those who contribute most value.
Exit mechanism
Pharaoh implements a unique exit burn where exit penalties are permanently burned. When users exit their xPHAR position early, 100% of the forfeited tokens are completely burned. This creates a powerful incentive structure where:
- Rewards scale with the protocol (user activity)
- Strong incentives to stay instead of locks
- Removes the need for locks or wrappers
- xPHAR solves the need for token lock-ups
- p33 (Liquid staked xPHAR) solves the need for liquid wrappers
Previous DEX Limitations
The history of decentralized finance has been marked by repeated attempts to solve the "DEX Trilemma" - the challenge of aligning incentives between traders, liquidity providers, and token holders. While Andre Cronje's metaDEX model theoretically solved this by balancing incentives between all participants—long lock-ups created a high friction system that forced users to lock tokens to participate equitably in the incentive model.
Credit to the Aerodrome team for the original graphic and concept.
Uniswap focused on a simple two-party system: traders and liquidity providers (LPs). metaDEX improved this by properly aligning incentives with token holders as well, but access to those incentives was unfair and heavily skewed towards protocols.
Uniswap | metaDEX | x(3,3) |
---|---|---|
|
|
|
The result? A more fluid and accessible system that still provides strong incentives, while removing much of the friction that still plagues ve-token models (token lock-ups).
Traders | Liquidity Providers | xPHAR |
---|---|---|
|
|
|
Directing Emissions
As discussed in our DEX Trilemma, prior to metaDEX users had no choice but to suffer from misaligned incentives from centralized parties. This led to inefficient capital allocation and reduced long-term sustainability for exchanges. x(3,3) solved this by putting emission control directly in the hands of xPHAR stakers who are incentivized to optimize for value.
Directing emissions is an extremely powerful use case for xPHAR stakers as it gives the holders primary power over what the platform incentivizes. If a token continually underperforms via fees, xPHAR holders are going to be less incentivized to vote for it, reducing incentives to it.
Less rewards from the pool = less emissions = less liquidity.
Each week, in what we call Epoch, xPHAR stakers make a choice on what liquidity pools to direct PHAR emissions to. Based on that vote which concludes every Thursday 00:00 UTC
, PHAR emissions are then directed to the chosen liquidity. You can read more about voting and how emission distribution is calculated here.
Voters earn swap fees and vote incentives in a lump sum immediately after epoch flip. These rewards are based on the liquidity you voted for in the previous epoch. If you vote for a liquidity pool in Epoch X, you will receive your accumulated rewards instantly when Epoch Y begins, proportional to your vote compared to the total votes.
Vote Incentives
On Pharaoh we utilize two different types of vote incentives: liquidity pool incentives & voter incentives. A vote incentive can be in the form of ANY whitelisted token. As a protocol, incentivizing your liquidity will attract voters and result in higher directed emissions. As an XPHAR staker, you earn a portion of the incentives.
A voter incentive is designated at anytime during the current Epoch and paid out in lump sum to xPHAR voters. It is displayed after the incentive is made and will influence votes until Epoch rollover.
A liquidity incentive is another method protocols can use to attract liquidity provision. This incentive is distributed directly to liquidity providers and is a great way to bootstrap new liquidity on the platform.
Voter Incentives | Liquidity Incentives |
---|---|
Paid as lump sum at epoch start | Distributed over 7 days after epoch |
Designated during current epoch | Used to boost pool visibility (direct yield) |
Influences votes until epoch rollover | Helps bootstrap new tokens |
Distribution | |
To voters at epoch flip | To LPs for full week after epoch |
A vote incentive can be in the form of any whitelisted token, and must be applied to only active gauges. Be sure to read & understand voting before participating.
Fees
Pharaoh's x(3,3) metaDEX model takes a straightforward approach to fee distribution:
- 100% xPHAR holders - All protocol fees flow to governance participants, incentivizing long-term alignment!
This creates a flywheel where:
- High-performing pairs generate more fees
- xPHAR stakers are more incentivized to vote
- Increased emissions attract deeper liquidity
- Deeper liquidity drives more volume and fees
Fee-Split
Fees-splits can be configured per gauge, below are the default fee-splits for all liquidity types:
With Gauge | No Gauge |
---|---|
100% to xPHAR | 0% to xPHAR |
0% to Liquidity Providers | 95% to Liquidity Providers |
0% to Protocol | 5% to Protocol |
Just like how our fees adjust to market volatility and volume, giving high-volume liquidity their fees back is just good business.
Example memecoin fee-split:
- 80% of fees go to xPHAR
- 15% creator fee (only memecoin launchers)
- 5% goes to LP
Dynamic Fees
Pharaoh's algorithm automatically adjusts fees based on market conditions and trading volume.
While dynamic fee mechanisms are not entirely novel—Pharaoh's dynamic fee algorithm monitors both DEX and CEX volume inflow. This leads to better performance, especially during volatile periods.
Fee Range | Market Conditions |
---|---|
Base: 0.05% Cap: 1.00% | Normal market conditions, Stable trading pairs, High liquidity pools |
Base: 0.30% Cap: 2.00% | Less liquid pairs, Higher volatility, Complex trading pairs |
Up to 5.00% | Extreme market conditions, Flash crash protection, MEV resistance |
Below is a visual of Pharaoh's dynamic fees versus Uni-V3: