Creating on-chain pools
Every field on the on-chain pool form — the activated chain it inherits, the two numbers that are its only terms, the per-pool intake switch, the commission that opens a notice period, and the liquid exit — plus the fixed-rate fields it refuses by name and why.
An on-chain pool is not a priced product. There is no rate to publish, no lock to choose, no capacity to allocate, no early-exit fee and no payout cadence: the network pays what it pays and an exit takes as long as the protocol takes. What you decide is which activated chain the pool sits on, the words its page carries, a floor, an optional cap, and the commission you keep on observed rewards. The venue, the staking wallet, the validator set, the slashing policy and the notice period are the chain activation's, and the disclosure a customer consents to is generated from all of it.
Create one at Extensions → Staking Services → Pools → New Pool
(/admin/staking/pool/new), edit one at /admin/staking/pool/{id}/edit.
Creating pools is the fixed-rate form and nothing on it applies here. For what the pool then does once a customer stakes into it, read How an on-chain stake moves.
Which form you get
There is one route and two forms. A new pool takes the product the platform
sells today — stakingMode in Staking settings. An
existing pool takes the product it was opened under, whatever the switch
says now: a fixed-rate pool edited on an install that has since moved to
on-chain staking still has its rate and its lock to edit, and an on-chain pool
never grows one. If the on-chain form is ever reached for a fixed-rate pool it
refuses rather than rendering controls the save would reject: the page reads
"Not an on-chain pool" and offers a way back.
The create route enforces the same rule server-side. A body whose mode
disagrees with the platform's is refused with a 400 naming which product is
being sold and where to change it, rather than being quietly overridden.
The chain list on this form is filtered to activations whose status is
ACTIVE. With none, the form shows no fields at all — only a link to
Chains. The wallet, the validator set, the commission notice and the
slashing policy are declared there, and a pool inherits them; see Chains,
wallets and validators.
Chain
One field you set, and eight facts you read.
Chain is a select over activated chains, shown as chain, venue and network. It is fixed at creation: on an edit the select is disabled, because the pool's venue, wallet and validator set were copied from that activation onto the pool row when it was created. A pool whose chain was later deactivated keeps showing its own chain in the disabled select rather than falling blank.
The strip beneath it is read-only and comes from the activation: venue,
network, staking wallet (truncated address and status), validator
set, slashing policy (pass through, or reimburse up to a cap per
incident), commission notice in days, licence and its regulator, and
blocked territories. None of them can be changed from this form. If one is
wrong, pause the activation and fix it there — and note that an ACTIVE
declaration cannot be edited in place.
The pool's symbol is never typed. It is set from the chain's own currency, so
it cannot disagree with the asset the engine will actually move.
Words
Name (2–100 characters), token name, icon URL, description, and two one-sentence fields: rewards and risks. Description, rewards and risks must not be empty; there is no ten-character minimum here as there is on the fixed-rate disclosure fields, because these are not the disclosure.
Rewards and risks arrive prefilled — "Whatever the network pays, observed each epoch, minus the commission stated in the disclosure" and "A network penalty reduces the pool's value for every holder. Nothing is insured" — and the create route writes those same two sentences when the body omits them. They are true of every on-chain pool, so leaving them is a reasonable choice; rewriting them to promise a rate is not.
Token name is fixed after creation: the field is disabled on the edit form, and the edit route does not read it even if something sends one.
The disclosure — custody, no guaranteed reward, the unbonding wait, slashing, the commission, and the five acknowledgements — is generated from the pool's rows and the activation's, and versioned by a hash of the material facts. It is regenerated on every save of this form. None of the text in this card reaches it, which is also why none of it can contradict it.
Terms
Three numbers, and they are the only terms an on-chain pool has.
| Field | Constraint | What it does |
|---|---|---|
| Minimum stake | ≥ 0 | The pool's own floor. |
| Maximum per stake | Blank, or strictly greater than the minimum | Per-position ceiling. Blank means no cap. |
| Commission on rewards, % | 0–100 | The share of observed rewards the platform keeps. |
The minimum is a floor, not the floor. The quote takes the larger of your number and the protocol's own — on Solana the minimum delegation plus the stake account's rent reserve, on Ethereum Lido's minimum withdrawal — so setting zero does not open the pool to dust, and setting a number below the protocol's does nothing at all. The figure the customer is shown is the effective one.
Where the commission comes from when you leave it blank, in order: the
chain activation's own default, then the platform-wide
stakingDefaultAdminFee. The activation wins because a per-chain figure is more
specific than a platform-wide one, and it is the number that chain's disclosure
was generated from. The field's placeholder shows the activation default so you
can see what blank will mean.
A commission rise is a notice, not an edit
This is the one field on the form that costs money to change, and the two directions behave differently.
- A cut applies at once. The new figure is written, and any pending rise is cancelled with it.
- A rise is stored as pending with an effective date the activation's notice
period away — thirty days when the activation does not say otherwise. The
current figure keeps applying until then. Every holder of a
PENDING_DELEGATIONorACTIVEposition in that pool is notified, once, naming both figures, the date, and that they may unstake at any time before it. The disclosure is regenerated and states the change and its date, so a new customer sees it too. The observer applies the pending figure on the first reward window after the date passes.
The disclosure version gates the next stake. Someone already in the pool never sees it again, so a change to their terms that only moved the version would reach them nowhere. That is why the commission rise and the liquid exit notify holders explicitly and the other fields on this form do not — nothing else here changes what an open position is worth or what its exit costs.
Listing
Status is ACTIVE, INACTIVE or COMING_SOON, and a new pool opens on
INACTIVE. Only ACTIVE takes stakes.
At most one ACTIVE on-chain pool may exist per asset, checked both when you
create one at ACTIVE and when you switch an existing one to it. The check is
scoped to the on-chain product: a fixed-rate pool for the same symbol does not
block an on-chain pool, and the reverse is also true, so the two products can
run side by side on one asset.
Featured on the landing page promotes the pool and has no economic effect. What a promoted on-chain card shows where a fixed-rate one shows a rate and a lock is under "What the staker sees" on How an on-chain stake moves.
Order is the sort position in the public list. Leave it blank on creation and the pool is appended after the current highest.
Intake — pausing one pool
Intake is OPEN or PAUSED, and it appears on the edit form only: a pool
is created OPEN and there is nothing to pause until it exists.
Pausing intake closes this pool to new stakes. It is one of four switches that can do that, and they are deliberately different sizes:
| Switch | Where | Closes |
|---|---|---|
| Pool intake | this form | one pool |
Pool status not ACTIVE |
this form | one pool, and it leaves the public list |
| Chain activation paused | Chains | every pool on that chain, with a reason shown at the stake door |
| Staking wallet frozen | Wallets | every pool on that key |
An unhealthy validator set and an open CRITICAL incident on the pool or its chain close intake too, without anyone flipping anything.
Reach for the pool switch when the reason is this pool — you want to stop taking SOL while a validator is being replaced, say — and the chain switch when the reason is the chain or the operator, because that one records a reason and says it to the customer.
Not one of them touches observation, unbonding, claims, returns or refunds. The kill switches are called from the stake door and from nowhere else, and a test over the source asserts that. A customer whose exit is already requested is unaffected by anything on this form, including deactivating the pool entirely.
Liquid exit
The card appears on an edit of a Lido pool only. The create route neither accepts nor stores these two fields, so a new pool always starts with the liquid exit off — and putting a control on the create form would have been a switch that silently did nothing. On Solana the card is not shown at all, because that engine has no such route and a switch there would have told that pool's stakers, through the disclosure, that their stake may be sold on a market it never reaches. The card keys off the activation's venue, and falls back to the pool's chain code when the activation is no longer ACTIVE, so an ETH pool does not lose the control the moment its chain is paused.
- Sell to release an exit — off on every pool, and turning it on notifies every current holder, naming the cap in per cent and saying an exit may still wait the queue. Turning it off is not notified: it can only return an exit to the protocol queue, which is what every holder agreed to when they staked.
- Most an exit may lose, in basis points — a whole number from 1 to 1000 (0.01% to 10%), defaulting to 100. Zero is refused because a cap of zero would refuse every sale; above 1000 is refused because it is not a cap. When the price on offer is worse than this against the protocol price, the sale is refused and the exit waits the queue exactly as before.
The disclosure says which of the two an exit gets either way — off, it states that the platform does not sell your stake to release it sooner; on, it quotes the cap as a number, because "some slippage" is not a term anyone can hold you to.
There is no test network with this market deployed, so the first real exercise of it is production. Turn it on first for a pool holding an amount you can afford to watch, and see one exit through end to end. What the engine actually signs, and what the firewall decodes before it signs, is on Operating on-chain staking.
What this form refuses, and why it refuses rather than ignores
Send any of these and the save fails with a 400 naming the fields you sent:
apr, lockPeriod, availableToStake, earlyWithdrawalFee,
earningFrequency, autoCompound, durations, externalPoolUrl,
profitSource, fundAllocation — and on an edit also capacityDelta,
walletType, walletChain and symbol. The check is for a value actually
present: null, an empty string and an empty array pass, so a form that sends
its whole shape with those keys blank is not punished for it.
Both routes refuse the same list in the same words, deliberately, so what the create accepts and what the edit accepts cannot drift apart.
They refuse rather than accept-and-null because they once did the latter: a body carrying a rate, a lock, a capacity, an early fee and a list of duration tiers was answered 200 while every one of those was written as NULL. An operator was told the pool had been created exactly as typed, and the terms had been dropped.
The columns are written NULL by construction rather than defaulted to zero, so a reader can tell "this pool has no rate" from "this pool pays nothing".
Deleting
Deletion is the shared pool door, and its guard covers the on-chain states as
well as the fixed-rate ones. A pool is refused deletion — soft or forced —
while it holds a position in ACTIVE, PENDING_WITHDRAWAL,
PENDING_DELEGATION, UNSTAKE_REQUESTED, UNBONDING or WITHDRAWABLE. Every
one of those is money the platform still owes somebody, including
WITHDRAWABLE, where the exit has settled and the return has not been paid
yet. Only COMPLETED, CANCELLED and FAILED rows are history. The database
association is RESTRICT too, so no path quietly destroys the debt.
Next: how an on-chain stake moves.