Staking Risks
What can go wrong when you delegate, and what we check before you sign.
Delegating is not the same as holding. These are the risks that actually apply to the pools and validators in our staking apps: the ones we check for you, and the ones nobody can check on your behalf.
On NEAR, some pools can change their own code
NEAR works differently from the other networks here. On Solana, Sui, Monad and Aleo,
delegating is something the protocol itself does. It holds your stake, and you keep the
authority to take it back. On NEAR, deposit_and_stake moves your NEAR into
the pool's own contract account. Whether you get it back depends on what that
contract's code does.
Almost every NEAR pool runs one of two contracts. The reference staking pool has no way to replace its own code, so what you inspect today is what runs tomorrow. The staking-farm contract does have an upgrade path: its operator can ask the factory for approved code and redeploy the pool. That path is authorised and documented, and it is not a flaw. It does mean the contract you delegated to is not fixed.
Where a pool runs an upgradeable contract, we say so on its row in the list and again in the staking form, and we will not let a deposit proceed until that has actually been shown to you. Two routes lead to new code and we check both: the contract's own upgrade method, and a full-access key on the account, which can deploy over it regardless of what the contract permits. One thing worth unlearning in the other direction: an empty key list on its own is not evidence that code is fixed, because a locked account can still act on itself through its own contract. "Locked" does not mean "unchangeable" anywhere you see it.
One of our own pools, stardust.pool.near, runs this contract. It is a farm
pool: the staking-farm contract is what lets a pool hand out additional token rewards on
top of the usual staking return, and the upgrade path comes with that design. We run it
because those rewards are worth offering, and we name it here because a disclosure that
skipped our own pools would not be worth much.
On Monad, your wallet can be pointed at the wrong chain
Monad is an EVM network, and an EVM wallet has one chain selected at a time. Your address is the same on all of them, so a wallet sitting on Ethereum or on a testnet still shows a perfectly plausible account on our Monad page. The page reads from Monad whatever your wallet has selected, which is exactly what makes this worth watching for: the balances and validators look completely normal.
Two things guard against it. A banner appears whenever your wallet is on any chain
other than Monad, with a button that switches it for you. And every transaction we
build names chain ID 143 outright, so a wallet on the wrong chain refuses
to sign instead of broadcasting somewhere else. You get told to switch networks, and
nothing is sent.
What we cannot fix from the page is the endpoint your wallet stores. When a wallet adds
a network it copies the endpoint from whatever added it, and keeps it permanently.
Wallets that added Monad from our old .fun address before September 2026
hold an endpoint that no longer exists, and Monad will fail for them in every
application until that network entry is edited or removed by hand. Our current pages
publish the public Monad endpoint instead, so nothing you add from here depends on us
staying online.
Before you approve anything, read the network name in your wallet's signing prompt. It is the only place that shows what your wallet is actually about to do.
What we verify, and what that is worth
Immediately before a NEAR deposit we read the pool's account state at a single finalised block, so those answers all describe the same moment, and confirm that:
- the account really does hold a contract;
- the contract is one of the implementations we have read the source of;
- the account carries no full-access key, since such a key could deploy new code over the pool whatever its contract allows. If we cannot read the key list, we stop rather than assume there is none;
- the commission still matches what you were shown, and sits within our 20% cap;
- the contract has not been replaced since we described it to you.
Two checks sit slightly outside that. Validator-set membership is confirmed for the current epoch, because that is the granularity the network publishes it at, not per block. And we ask NEAR's staking-pool whitelist about the pool: an explicit "no" stops the deposit, but if the whitelist cannot be reached we continue without it rather than making your stake depend on that registry being up. So a permitted deposit means the whitelist did not object, which is not the same as the whitelist having confirmed it.
If any of those fails, nothing is signed and we tell you which one it was. Solana gets the equivalent treatment: the vote account is re-read from the chain for existence, delinquency and commission before the transaction is built.
What this is not is an audit. We match a pool's contract against a published release artifact rather than against a build we reproduced from source ourselves, so it rests on trusting that artifact. And it describes one moment: a pool with an upgrade path can legitimately change its code after you delegate, and nothing we check at signing time constrains what happens afterwards.
Commission can change after you delegate
Commission is set by the operator and can be raised at any time. We refuse a deposit if the figure moved between the moment you chose the pool and the moment you signed, and we mark pools charging above our cap as unstakeable. Several NEAR pools charge 100%, which takes every reward. None of that stops a pool raising its fee weeks later, though. Reward figures anywhere in our apps are estimates from current network conditions, not a promise.
Your stake is not liquid
Every network here has an unlock period, measured in days rather than minutes. Unstaking begins a wait before the funds can be withdrawn, and on some networks a second unstake request restarts that wait from the beginning. Do not delegate anything you might need during that window.
Validator performance, and slashing
A validator that goes offline or misses its duties earns less, and your share of the rewards falls with it. Some networks also penalise validators for misbehaviour, and a delegator's stake can be reduced along with the operator's. Choosing a low commission is not the same as choosing a reliable operator. Our list is ordered by commission because that is the one figure an operator sets and controls, not because the top row is the best choice for you.
Things no interface can protect you from
- A wallet or browser extension that has been compromised.
- Approving a transaction you have not read. Every one of our apps shows the full destination before signing, meaning the complete pool account or validator identity, never a shortened version or a nickname.
- Sending to an address you typed or pasted incorrectly.
- Changes made to the network protocol itself.
We publish what we find, including when it concerns our own pools. If anything here is wrong or out of date, tell us at admin@stardust.pub. See also our security page and terms of use.