Stella
Stella tokenomics linked STELLA lock size and duration to voting power
Stella tokenomics connected STELLA supply, liquidity incentives and fee-sharing through governance locks whose voting power depended on token amount and remaining lock duration. The exchange, StellaSwap on Moonbeam, ended operations on 31 July 2026, so these rules describe its historical economic design. Its revised maximum supply was 250 million STELLA, down from the original 500 million. Holders locked STELLA to obtain veSTELLA, an NFT that carried voting rights over pool incentives. Longer commitments increased voting weight, while that weight declined as expiry approached. Pool emissions, voter earnings and the underlying locked tokens each had separate economic roles.
Locked STELLA and Time-Weighted Voting Power
A veSTELLA position converted a commitment of STELLA into governance weight, with both the token amount and the chosen lock duration affecting that weight. The maximum two-year setting used a ratio of one veSTELLA voting-power unit per locked STELLA. The NFT represented the lock itself; its voting-power units described the influence attached to that position.
Manually managed voting power decayed linearly as the lock approached expiry. An unchanged STELLA amount could therefore carry less voting influence later. The locked amount and the power attributed to it were separate quantities, which mattered when interpreting an older position or comparing voting records from different epochs.
Reduced Supply and Reserved Allocations
The revised supply framework replaced the original 500 million STELLA ceiling. The revised maximum supply was 250 million STELLA. That figure described the tokenomics framework before closure; circulating supply was a separate quantity.
The reduction involved minting and burning the excess 250 million STELLA. This supply-reduction mechanism differed from the fee-funded market buybacks that supported the earlier xSTELLA pool.
Reserved allocations used the revised 250 million STELLA base. The plan allocated 10% to ecosystem growth, 12.5% to treasury and 12.5% to development. Their vesting plan specified quarterly unlocks over five years, from January 2022 through January 2027.
Vesting and weekly pool emissions followed different schedules. The January 2027 endpoint belonged to the reserved allocation plan; exchange operations ended earlier.
Declining Emissions and Pool Incentives
The vote-escrow emissions schedule specified an initial rate of 40 000 STELLA per day, reducing the emission amount by 0.25% each weekly epoch. Its initial weekly allocation was 280 000 STELLA. These figures belonged to the historical schedule.
Emission reductions changed the rate of incentives reaching liquidity pools. A smaller weekly budget could reduce the tokens available to support liquidity provision even when a pool retained its share of votes. Net token supply grew when minting exceeded burning and fell when burning exceeded minting. Locking and burning had different effects: a lock committed tokens for a term, while a burn permanently removed tokens from supply.
Pool Votes and Separate Reward Streams
Emissions for Liquidity Providers
Pool votes directed weekly STELLA incentives toward selected liquidity pools, linking governance choices to rewards for supplying liquidity. A governance lock and a liquidity deposit remained different positions. Voting weight affected a pool's incentive allocation. Ownership of pool assets arose from the liquidity position.
Fees and Vote Incentives for Voters
Pool voters shared in trading fees from the pools that they supported. Their pool selections therefore affected the revenue available to them. Vote incentives, commonly called bribes in this model, added a separate reward for directing votes toward a particular pool. These payments and the STELLA emissions assigned to liquidity pools had different recipients and purposes.
Active participation mattered in each epoch. Voters could assign their full weight to one pool or divide it among several pools. A lock's voting power and the pool's revenue affected earnings within that period.
Changes to Lock Size, Duration and Ownership
Additional STELLA and Longer Commitments
Increase added STELLA to an existing lock. Extend lengthened its term where the lock had not reached the two-year maximum.
Merged Locks and Transferred Rights
Merging combined locks into a position that inherited the longer lock duration. Splitting created separate locks that retained the original duration. Transferring a lock passed its ownership, rights and earnings to the recipient.
STELLA and USDC Relay Strategies
Relay strategies automated voting for deposited veSTELLA locks, with different destinations for the earnings that those votes generated.
STELLA Optimizer
STELLA Optimizer converted earnings back into STELLA and reinvested them in a maximum-duration lock. Its design sought to increase the locked amount and maintain voting influence through compounding. Leaving the strategy and unlocking the underlying tokens were different operations. A strategy-managed lock could return with a renewed two-year commitment, so withdrawing its NFT did not mean recovering freely spendable STELLA.
USDC Optimizer
USDC Optimizer converted earnings into USDC for claiming, rather than using those earnings to enlarge the STELLA commitment. Its voting power remained exposed to time decay. Reward claims concerned USDC, while the underlying lock held STELLA.
A Legacy Vote's Commitment Boundary
The legacy voting process required a veSTELLA lock and an active epoch. Pool selection and weight settings were preparatory choices. The completed onchain vote committed the allocation until that epoch ended.
For a previously submitted vote, reconciliation starts with the lock that carried voting rights at the transaction time.
- Match the transaction's lock identifier to the NFT that held voting rights at submission.
- Confirm that the chosen pool weights totaled 100% before commitment.
- Check the completed onchain vote instead of treating a wallet confirmation prompt as completion.
- Match that transaction to the historical dashboard's Voted status for the same lock and epoch.
- Reconcile reward receipts separately; a recorded vote alone did not establish that a reward reached a wallet.
StellaSwap's closure ended the operating service. A saved voting screen could describe a past action without establishing an available governance round today.
Early Unlocks and Burned Penalties
Breaking a lock before expiry incurred a penalty of 50% of its locked STELLA, which was burned under the historical withdrawal rule. Unlocking also destroyed the lock and surrendered its voting power.
Waiting for the term's end and transferring the NFT were distinct from breaking a lock early. A transfer changed ownership without establishing a token redemption. After closure, an old Unlock label alone did not establish which withdrawals a contract or interface supported.
The Earlier xSTELLA Redemption Model
The earlier xSTELLA model represented a share of pooled STELLA and had no timelock in its historical design. Swap-fee revenue funded STELLA buybacks that added to the pool's backing. A holder's redemption quantity depended on the STELLA held by the pool relative to outstanding xSTELLA shares.
The receipt quantity and the underlying STELLA claim were different measures. Fee-funded purchases could increase the STELLA attributable to each share without increasing the shares in a wallet. That accounting relationship concerned token quantities; it did not fix their value in money.
Compared with xSTELLA's untimed redemption design, veSTELLA attached governance influence to a timed commitment. The relevant exit terms followed the position itself: a pooled STELLA claim for xSTELLA or a lock with early-withdrawal penalties for veSTELLA.
Practical questions
When Did the veSTELLA Voting Epoch Close Each Week?
The historical veSTELLA voting schedule specified an epoch cutoff of 23:59 UTC on Thursdays. Each epoch covered one week of voting for pool allocations and associated rewards. That timetable belonged to the operating protocol before closure; it does not establish an available voting round today.
Could a Protocol Attract Pool Votes Without Acquiring Its Own veSTELLA Lock?
A protocol could fund vote incentives for its pool instead of acquiring STELLA and locking it for direct voting. Those incentives sought votes from existing veSTELLA holders. The alternative was to obtain a lock and allocate its own voting weight, making incentive funding and direct governance participation separate approaches.
Which Relay Strategy Charge Came Out of Earned Rewards?
The 1% relay deposit fee came out of rewards in the historical auto-strategy design. That charge belonged to automated lock management. It was separate from voting-power decay, which changed governance weight, and from the burned penalty associated with breaking a lock early. These mechanisms affected different parts of the position.
Why Could USDC Rewards Remain Unclaimable Immediately After a Relay Deposit?
USDC Optimizer claims became available after the first epoch passed in the historical relay design. Each epoch lasted one week. A completed strategy deposit therefore preceded the initial claim window, and the timing of USDC reward claims remained separate from the underlying STELLA lock's expiry.
Could a Past veSTELLA APR Establish a Fixed Payout for a Later Epoch?
A past veSTELLA APR did not establish a fixed payout for a later epoch. The voting model tied earnings to the pools that received a lock's votes, their fee generation and vote incentives. An annualized rate did not record the tokens subsequently distributed to a lock.
Was a Token Approval Enough to Create a veSTELLA Lock?
A token approval alone did not create a veSTELLA lock. The historical interface used approval to authorize STELLA use, followed by locking to create the NFT position. An approval record established authorization; the created lock and its recorded token amount established the committed position.