What is fixed APR (Linear) staking?
Fixed APR staking, also called Linear staking, pays each staker a set annual percentage rate on the tokens they lock, funded from a reward reserve the project sets aside in advance. Lock 1,000 tokens into a 20% fixed-APR pool and you earn roughly 200 tokens over a year, whatever else happens to the size of the pool, as long as the reserve actually holds enough to pay it.
That last clause matters. Fixed APR staking is not the same as protocol-native staking, where new tokens come from the chain itself. Ethereum's proof-of-stake rewards, for instance, are minted by the protocol: roughly 33% of ETH's supply, near 39 million ETH worth about $80 billion, is staked across more than 1.2 million active validators, and the native reward has compressed to around 2.78% APR as more validators have joined, per StakingRewards and other on-chain trackers. A project-run token has no protocol issuance to lean on. Every reward paid out of a fixed-APR pool has to come from tokens the project actually deposited, which is why Saleium's staking pools tie a configured rate to a funded reserve rather than a promise.
What is allocation (MasterChef) staking?
Allocation staking, widely called MasterChef staking after the contract SushiSwap popularized in 2020, pays no fixed rate at all. The pool defines a fixed reward emission per block or per period, and splits it across every staker pro rata by their share of the pool, their allocation points. Add more stakers, and each existing staker's slice of that same fixed emission gets smaller automatically.
This makes allocation staking self-balancing on the payout side: the project only ever emits what it scheduled, no matter how many wallets join. What moves is not the total reward but each staker's cut of it. A staker who joins early, when the pool is small, earns a larger share per token staked than one who joins after the pool has grown crowded. There is no promised number to publish, which is both the model's strength and the reason it can be a harder sell in marketing copy than a plain APR.
Fixed APR vs allocation staking: which model fits your token?
Fixed APR suits a project that wants a specific rate to advertise and can commit to funding it. Allocation suits a project that wants reward emissions capped and predictable from its own side, with the per-staker rate left to float. Neither model is safer by default: fixed APR needs a properly funded reserve, and allocation needs a well-set emission schedule, but the two fail in different ways when they are not.
| Fixed-APR (Linear) | Allocation (MasterChef) | |
|---|---|---|
| How rewards are set | A stated annual rate paid on each staker's balance | A fixed reward emission split pro rata across all stakers |
| Who bears APR risk | The project, if the reserve cannot cover the promised rate | Stakers, whose individual rate falls as more wallets join |
| Best for | A predictable, marketable rate for long-term holders | Rewarding early participation without a fixed payout promise |
| Funding requirement | Reserve must cover the full advertised rate for the whole term, at any participation level | Reserve only needs to cover the fixed emission, regardless of how many stake |
The funding requirement row is where most DIY staking pools get into trouble, and it is worth a section of its own.
Why do DIY staking pools silently fail?
DIY staking pools fail silently when a project sets a fixed APR without checking whether the reward reserve can actually cover it at the level of participation the pool ends up attracting. The contract still promises the same rate to everyone who staked, so if the reserve was funded for an estimated amount and more tokens actually lock in, the pool owes more than it holds.
The failure is silent because nothing looks wrong at launch. The pool page shows a healthy APR, stakers lock their tokens, and the contract accrues rewards exactly as coded. The problem only surfaces when someone tries to claim: either the claim transaction reverts because the contract cannot pay it, or early claimants drain the reserve and everyone who claims later gets a partial payout or nothing. By the time that happens, the project has already marketed a rate it could not structurally deliver, and the damage to trust is worse than if the APR had simply been set lower from the start.
This is easy to miss during testing, too. A pool tested with a handful of wallets and a short lock period looks completely healthy, because the reserve never comes close to its limit. The gap only shows up at real scale, weeks or months after launch, once enough stakers have accrued enough unclaimed rewards to exceed what the reserve was ever funded to cover.
What is reward-funding safety, and how does Saleium prevent that?
Reward-funding safety is a check built into Saleium's staking contracts that ties an advertised rate to what the reward reserve can actually cover, so a pool cannot promise more than it can pay and claims do not fail after the fact. Instead of trusting a project's manual estimate of expected participation, the contract enforces the relationship between rate, cap and reserve directly.
In practice, this means a fixed-APR pool's maximum payable obligation is bounded by its configured cap and its funded reserve, so the pool cannot silently outgrow what it can pay as more stakers join. Reward payouts route through the same kind of audited transfer pattern that OpenZeppelin's Contracts library uses to guard token transfers, and Saleium's staking contracts sit in the same CertiK-audited stack behind ChainGPT Pad. The result is the same underlying failure DIY pools run into, just closed off by the contract instead of left to hope.
Which model fits an early-stage token vs an established one?
An early-stage token, where nobody yet knows how much will actually stake, fits an allocation pool better: the emission is fixed no matter how participation turns out, so there is no reserve size to misjudge. An established token with steadier holder behavior can budget a fixed-APR pool more confidently, because the likely range of participation is narrower and easier to fund for.
Some projects use allocation pools for a bootstrap phase, rewarding whoever shows up first without guessing at a rate, then move to a fixed-APR pool once staking demand has settled into a predictable range. Others run both permanently: an allocation pool for a limited campaign and a fixed-APR pool for holders who want a number they can plan around. There is no wrong choice here, only a mismatch: an allocation pool advertised as if it paid a guaranteed rate, or a fixed-APR pool sized for a fraction of the tokens that actually show up to stake.
How do caps, lock periods and join windows change each model?
A pool cap changes what each model needs to stay solvent. On a fixed-APR pool, the cap sets the ceiling on total reward obligation, the cap multiplied by the rate, which is exactly the number the reserve has to cover. On an allocation pool, a cap is not load-bearing for solvency the same way, since the emission itself is already fixed, though a cap can still be used to control how concentrated the pool gets among a few large stakers.
Lock periods and join windows work the same way across both models: they set how long a stake commits and when the pool accepts new entrants. What differs is the consequence of getting these settings wrong. A fixed-APR pool with no cap and a long lock period is a project underwriting an open-ended promise; an allocation pool with the same settings just changes how thin the fixed emission gets spread.
What does staking cost on Saleium?
Staking on Saleium costs a percentage of the rewards distributed, not a fee on the principal staked. The base rate is 5%, reduced by plan to 4.75% on Growth, 4.50% on Pro, and 3.75% on Business and Enterprise. That fee applies whether the pool runs fixed-APR, allocation, or both.
Because the fee comes out of rewards rather than principal, stakers keep their full staked balance available to unstake per the pool's rules, and the project's cost scales with what it actually pays out rather than with how many tokens are locked. Full plan details, including each tier's raise cap for a token sale run alongside staking, are on the pricing page.
Can you run both pool types on the same token?
Yes. A project can run a fixed-APR pool for stakers who want a predictable, advertised rate alongside an allocation pool for a shorter incentive campaign, on the same token, at the same time. Saleium supports configuring multiple pools per project, each with its own cap, minimum and maximum stake, lock duration, delay and join window.
This is common for projects that launched via a white-label staking platform and want to segment rewards: a long-term fixed-APR pool for holders who staked at launch, and a time-boxed allocation pool tied to a later campaign or a token sale. Both pool types share the same underlying reward-funding safety, so mixing them does not reintroduce the risk either model carries on its own. For definitions of the staking terms used across these pools, see the glossary. Whichever model you pick, the reward reserve behind it is what actually determines whether stakers get paid.