> For the complete documentation index, see [llms.txt](https://docs.ekubo.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ekubo.org/products/ve33.md).

# Ve33 and STONX

Ecosystems — chains, protocols, launchpads — often need liquidity across a set of related markets. **Ve33** turns that into a marketplace: holders lock a stake token, direct emissions to the pools they want liquidity in, set those pools' fees, and earn the trading fees the pools generate. Because voters are paid from the fees of the pools they support, they have a direct financial stake in allocating well.

Ve33 is an [extension](/concepts/extensions.md) on Ekubo Core. Anyone can deploy an instance around a token of their choice, including an existing token. It is permissionless and ownerless: no admin, no treasury cut, no weekly epoch, and emission policy lives outside the base extension.

The design descends from Curve's veCRV and Solidly's ve(3,3) — later refined by Velodrome and Aerodrome — with one significant addition: **voters set the pool fee**, not just the emission share. Background and economics: [Ve33: a token-governed liquidity marketplace](https://hackmd.io/@moodysalem/r1VnZQr4fg).

## Tokenomics

**Locking.** Holders lock the stake token for up to four years. Voting power is linear in both size and remaining time:

```
voting power = stake amount × (unlock time − now) / 4 years
```

A lock is represented by a transferable ERC-721 through the `VeToken` wrapper, whose metadata and SVG image are rendered entirely on-chain. Stakes can be increased, extended, split into several positions, or merged.

**Voting.** A stake assigns its full voting power to one pool — split a stake to support several. Each vote carries two decisions:

1. **Emissions** — the pool's share of the global emission stream
2. **Fee** — the swap fee that pool charges

The active pool fee is the voting-power-weighted average of all fee votes on that pool. A pool with no active vote weight charges a zero extension fee.

**Who earns what.** This is the part that differs most from an ordinary AMM:

| Participant             | Earns                                                                                                 |
| ----------------------- | ----------------------------------------------------------------------------------------------------- |
| **Voters**              | The full swap fees of the pools they vote for, proportional to vote weight — no treasury share        |
| **Liquidity providers** | Emissions of the stake token, by pool vote weight and their active liquidity — **not** Core swap fees |

LP rewards are range-aware: concentrated positions earn while in range, using the same inside/outside accounting Core uses for fees. Stableswap positions use global pool reward growth.

**Continuous accounting.** Unlike weekly-epoch ve(3,3) systems, fees and emissions accrue through on-chain growth indices updated whenever a pool or position is touched. There is no weekly distribution transaction. Vote weights, by contrast, are *sampled* — stored pool weights change only when a vote is cast or refreshed, so stake owners should renew votes as locks approach expiry.

**Emissions are modular.** Anyone can fund an emission schedule over a chosen interval by calling `scheduleEmissions(startTime, endTime, rate)` through the Ve33 periphery. Emission policy therefore lives outside the extension: a community can place the funding source — a mint authority, a treasury, or anything else — under whatever governance it prefers.

Because Ve33 pools use Ekubo Core underneath, they inherit singleton settlement, flash accounting, high-precision concentrated liquidity, stableswap support, and the shared routing surface. Swaps must be forwarded through a Ve33-aware router — direct Core swaps revert, since the voter-selected fee is applied by the extension.

## STONX on Robinhood Chain

**STONX** is the first ecosystem deployment of Ve33: a stake and reward token for bootstrapping capital-efficient **stock token liquidity** on [Robinhood Chain](https://robinhood.com/us/en/newsroom/robinhood-chain-launches-public-testnet).

{% hint style="info" %}
STONX is a [DAO proposal](https://hackmd.io/@moodysalem/stonx-on-rhc) under discussion. Details are subject to change and it will not proceed without Ekubo DAO approval on a specific version.
{% endhint %}

As proposed, the launch mints **999,999 STONX** in three equal parts:

| Allocation    | Amount        | Purpose                                                               |
| ------------- | ------------- | --------------------------------------------------------------------- |
| Ekubo, Inc.   | 333,333 STONX | Max-staked to direct initial emissions and fund continued development |
| DAO liquidity | 333,333 STONX | Paired with 333,333 USDG as DAO-owned STONX/USDG liquidity            |
| Emissions     | 333,333 STONX | 100 days of bootstrap emissions (about 3,333 STONX/day)               |

The DAO would pair its allocation with 333,333 USDG in a STONX/USDG Ve33 pool at an initial price of $1.00 per STONX, with the DAO's position spanning the full usable tick range, funded by selling existing DAO liquidity positions on Ethereum.

**Emission policy.** The initial 333,333 STONX is scheduled directly through the Ve33 periphery over **100 days**, an average of about **3,333 STONX/day**, to bootstrap liquidity. Because a funded schedule is committed on-chain, emissions already scheduled cannot be withdrawn or reduced; further emissions require funding a new schedule.

**What the DAO controls.** STONX mint authority is transferred to governance through the owner proxy on Robinhood Chain. This is the DAO's *only* form of ownership over the system: it can approve additional mints — to fund further emission schedules, partnerships, or distributions — by proposal. It cannot control votes, fees, or existing liquidity, and cannot claw back emissions already scheduled.

Ekubo, Inc. would max-stake its allocation and direct initial votes toward stock-token markets, with the resulting fee income funding development and maintenance.

The open questions are the ones voters answer continuously: which stock-token markets deserve emissions, what fee gives traders competitive execution while producing useful voter revenue, and whether the volume that follows each unit of emissions justifies the issuance.

## For developers

* [Ve33 user guide](https://github.com/EkuboProtocol/evm-contracts/blob/v3.2.0/docs/ve33-user-guide.md) — operational detail, including vote clearing, reward claiming, and expired stakes
* [Architecture notes](https://github.com/EkuboProtocol/evm-contracts/blob/v3.2.0/docs/ve-integrated-extension.md)
* [`Ve33.sol`](https://github.com/EkuboProtocol/evm-contracts/blob/v3.2.0/src/extensions/Ve33.sol), [`VeToken.sol`](https://github.com/EkuboProtocol/evm-contracts/blob/v3.2.0/src/VeToken.sol), [`Ve33Periphery.sol`](https://github.com/EkuboProtocol/evm-contracts/blob/v3.2.0/src/Ve33Periphery.sol)

The Ve33 accounting is covered by unit, fuzz, and stateful invariant tests for stake backing, voter-fee solvency, emission solvency, vote consistency, and range-aware LP rewards — see [Audits](/reference/audits.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ekubo.org/products/ve33.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.