Solidly
Solidly voting directs weekly SOLID emissions to pools chosen by veSOLID holders
Solidly voting lets veSOLID holders direct weekly SOLID emissions toward liquidity pools. Their rewards come from the pools receiving their votes, through trading fees and voter bribes. Comparing those payments requires separating voter income from liquidity provider (LP) incentives and matching each figure to its reward period.
· updatedVoter incentives and LP incentives have different recipients
In V3, voter bribes pay veSOLID holders, while direct LP bribes pay liquidity providers. That recipient determines which incentive belongs in a voting comparison. SOLID emissions also reward liquidity provision, although votes determine their allocation. Substantial LP earnings can coexist with a small voter reward budget.
| Earning option | Reward source | Recipient | Pool or position scope |
|---|---|---|---|
| Voter fee income | Trading fees | veSOLID voters | Pools receiving their votes |
| Voter bribes | Deposited incentives | veSOLID voters | Incentivized pools receiving their votes |
| LP fee income | Trading fees | Liquidity providers | Active V3 liquidity |
| SOLID emissions | Protocol emissions | Liquidity providers | Pools receiving emission allocations |
| Direct LP bribes | Deposited incentives | Liquidity providers | Funded pools or specified liquidity ranges |
Several earnings can coexist in one pool, although only voter fees and voter bribes describe income from supporting it with veSOLID. A combined reward figure that includes LP incentives answers a different question about participating in that pool.
Locked SOLID sets the voting power available to allocate
veSOLID is a vote-escrowed position, represented by a non-fungible token (NFT) under the ERC-721 standard. Locked SOLID backs the position, and the locked amount and remaining term determine its voting power. That remaining term scales weight against the four-year maximum, with power decreasing linearly as time passes.
For equal locked balances, less remaining lock time means less voting power. Counting NFTs therefore cannot establish how much influence a holder has. The relevant input is the weight that the position can allocate to pools.
How do pool fees and voter bribes change the choice?
Trading activity generates pool fees, while voter bribes add a separate budget for attracting emission votes.
Trading fees reflect paid swap activity
Solidly V3 assigns 20% of pool trading fees to veSOLID voters. This is a share of collected fees, not a 20% charge on a swap. Liquidity providers receive the remaining 80%. A holder's own fee earnings also depend on their eligible share of the pool's voting weight. Trading volume alone leaves out the fee that the pool charges. Adaptive fees can change with market conditions, so equal volumes need not generate equal fee income. Pool size also does not show how much trading fee revenue reaches voters.
Voter bribes have a funded distribution period
A sponsor supplies voter bribes to attract votes for a pool. The deposit's distribution period defines which reward budget belongs in the comparison. A budget covering several periods cannot be treated as a fresh payment for every weekly allocation.
Fees and bribes can contain different tokens, so raw token counts cannot be added as one asset balance. A dollar valuation supplies a common comparison unit, while the prices used in that valuation can change.
Voting APR changes as eligible weight shares the budget
The denominator is the pool's eligible voting weight
Pro-rata rewards depend on the eligible voting weight sharing the pool's reward budget. Dividing a position's qualifying weight by the eligible total gives its share for that distribution. An unchanged bribe budget therefore pays less per unit when additional weight qualifies. Votes across pools determine emission allocation, while the qualifying weight within a pool determines individual shares of its voter bribe. A large budget spread across heavy voting support can produce a modest return per unit of voting power.
The period must match the annualized figure
An annual percentage rate (APR) expresses a rate over a year. A displayed voting APR annualizes its underlying reward inputs; it is not a token balance ready for payment. Its usefulness depends on those inputs, including the distribution period and weight sharing the rewards. Comparing an accrued fee amount with a future bribe budget mixes different time bases unless the calculation accounts for that difference.
A pool target includes its chain and contract version
The same token pair can identify different pools across deployments. A voting target therefore needs its chain and contract address. Solidly's networks have separate pools and reward accounting, so a familiar pair name cannot establish that two displayed opportunities concern the same pool.
Original Fantom V1 and subsequent V3 deployments use different reward machinery. V1 gauges distributed pool incentives, with separate contracts handling fees and bribes. V3 combines reward accounting through its Rewards Distributor. Historical V1 contract behavior needs that version context when interpreting a vote.
Within V3, a token pair can also have separate pools at different tick sizes. A tick is a permitted price step, and tick size controls the spacing of position boundaries. The pool address distinguishes those targets even when their token names match.
Original V1's stored votes identified the allocation by veNFT token ID and pool; reward balances recorded earnings separately.
Why can voter rewards remain pending after a vote?
V3's off-chain reward calculations need an on-chain update and a completed security buffer before claims open. That update publishes a Merkle root, which lets the distributor verify reward claims using proofs. The buffer gives challengers time to contest a new root. V3 rewards must be claimed on the chain where they were earned. Pending describes earnings awaiting the sync, while Claimable identifies ready rewards. Pending status alone does not show that a pool choice failed.
Sponsors can attract votes or reward liquidity directly
A protocol seeking emission votes can fund voter bribes for its pool. Those payments encourage veSOLID holders to allocate weight toward that target. The final allocation follows voting weight, so the funded budget attracts participation without fixing the quantity of SOLID emissions awarded.
Direct LP bribes support liquidity provision without requiring the payment to pass through voters. V3 also supports customized incentives for specified concentrated-liquidity ranges. A sponsor can therefore target the liquidity that it wants to attract. That range-specific payment belongs to eligible LP earnings, separately from any voter bribe offered for the pool.
Fee demand and funded incentives have different time horizons
A funded bribe covers its distribution period, while future trading-fee income requires further fee-generating swaps. Comparing pools across weeks therefore involves both trading demand and the incentive budget for the relevant period. A large current deposit cannot establish the size of a later deposit. More voting support can also change how widely the available rewards are shared.
Past fee income describes activity that already generated revenue. An offered voter bribe describes an incentive budget. Neither amount alone establishes the holder's eventual token payment. Gas for claiming is a separate transaction cost, whose size relative to the reward matters for small accrued balances. Under V3's 20% voter fee allocation, a large bribe can coexist with little trading-fee income.
Common questions about Solidly voting
Which tokens are paid as V3 voter trading fees?
V3 distributes voter trading-fee rewards in the underlying token currencies of the pair. SOLID emissions are a separate reward stream for liquidity providers. A SOLID emission figure therefore cannot stand in for the token amount owed as voter fee income. The reward rows identify token amounts separately from their dollar valuations.
Can I acquire voting power through a transferred veSOLID NFT?
An unexpired, transferable veSOLID NFT can give its new holder an existing locked voting position. The original V1 contract permitted transfers only when the NFT had no gauge attachments and was not marked as voted. The position's locked amount and remaining term determine its power. Transferability alone does not establish resale liquidity.
Does a V3 pool's tick-size label state its current trading fee?
The tick-size label identifies price spacing, while the trading fee is a separate pool parameter. V3 pools start with a default fee associated with their tick size, and adaptive fees can change. The voter fee share applies to the fees that swaps actually generate, so the chip alone cannot specify voter fee income.
Who could cast a vote for a veNFT in original V1?
The original V1 voting contract allowed the veNFT owner, a specifically approved address or an approved operator to vote. It checked authorization for the token ID supplied with the allocation. Holding loose SOLID did not provide authority to change another position's votes.
Why did a tiny relative weight sometimes fail in the original V1 voter?
Original V1 rejected a recognized gauge allocation when its calculated voting weight rounded to zero. The contract scaled the submitted relative weight using the veNFT's voting power and integer division. A nonzero input could therefore produce a zero allocation after calculation. The submitted weight and the resulting pool weight were different quantities.
Could original V1 allocations be refreshed without selecting different pools?
The original V1 voter exposed poke to recalculate a veNFT's stored allocations using its voting power at that time. It reused the stored pool list and relative weights, refreshing the weight calculations without choosing different pools. The amount of available voting power still came from the underlying lock.
Was repeating a pool allowed in one original V1 vote?
The original V1 voter rejected repeated allocations to the same recognized pool within one submission. After assigning a nonzero weight, the contract required that pool's stored vote to be zero before accepting another entry. This restriction concerned duplicate entries within the submitted pool list; it did not prevent a holder from replacing an earlier allocation.