Staking settings

The ten platform settings that govern staking, what each one actually changes, and which of them behave differently when never saved than the screen suggests.

7 min readUpdated 12 August 2026settings, configuration, distribution, approval

Staking has ten settings, all stored in the platform settings table with a staking prefix and edited at Extensions → Staking Services → Settings (/admin/staking/settings, permission access.staking.settings). Two tabs: Platform and Earnings.

They are platform-wide. None of them can be varied per pool.

The settings screen shows a display default for every field, and the save only sends keys whose value actually changed. On a fresh install nothing has been saved, so most of these keys do not exist in the database at all — and each backend reader decides for itself what an absent key means.

Most of them agree. The exceptions are called out where they appear, and there are two kinds:

Three pre-fill defaults — admin fee, early-withdrawal fee and auto-compound — where the new-pool form falls back to a different figure than the settings screen displays. These only affect what the creation form suggests; no live pool or position reads them.
One live gate — the earnings distribution hour, where an absent or malformed value runs the distribution every hour while the screen shows 00:00.

stakingRequireWithdrawalApproval used to be a third case and is no longer — see the note on it below.

If you care about any of these, change the value, save, change it back and save again. That writes a real row and removes the ambiguity.

Platform tab

Pre-fills the admin fee on the new-pool form. Not applied to existing pools.

A convenience default only. The pool form falls back to 10% when the key is absent, not to the 0 the settings screen displays. Changing it never touches a pool that already exists, and never touches a position — positions snapshot the fee at stake time.

Pre-fills the early-withdrawal fee on the new-pool form.

Same shape. The pool form's own fallback when the key is absent is 5%.

Pre-fills the auto-compound switch on the new-pool form.

Same shape again. All three of these are form conveniences and nothing else — no reward calculation reads them.

Earnings tab

Method used to convert APR into a reward. Applies to every pool and every position.

SIMPLE or COMPOUND. This is the one setting that changes what people are paid. Absent or unreadable resolves to SIMPLE.

Switching it mid-flight is safe in the sense that nothing breaks, but it changes the target curve for every live position, including ones already part-paid. Because accrual pays the difference between the target and what has been credited, moving from COMPOUND to SIMPLE can put a position temporarily ahead of its curve and freeze its rewards until wall-clock time catches up. Decide before you launch.

Automatically credit periodic rewards on the hourly cron run.

Governs intra-term accrual only. Maturity settlement — returning principal at the end of a lock — always runs regardless, because holding capital past an agreed term is not a configuration option.

An absent key is treated as on. That matches the switch's display default, so this one is not a trap: a fresh install does distribute rewards. Turn it off only if you intend to distribute by hand from the Earnings screen; positions will accrue nothing until you do.

Restricts periodic distribution to one hour of the day. Written as a 24-hour clock time, server-local.

The field takes an HH:MM string. Only the hour is compared — the minutes are ignored, so 14:30 and 14:00 behave identically. Outside that hour the cron settles matured positions and does nothing else. The screen's display default is 00:00.

Absent, blank, or malformed values fall back to running every hour, so a typo degrades to more frequent distribution rather than silently halting it. Skipping hours never shortchanges anyone: accrual is delta-based, so the next qualifying run credits the full outstanding amount.

Smallest position a user may withdraw. Compared against the whole position.

There is no partial withdrawal in this product, so this is not a minimum withdrawal amount in the usual sense — it is a floor on which positions their owner is allowed to exit at all.

The setting is a bare number with no currency attached, and it is checked against the position's amount in whatever the pool is denominated. A value of 100 means 100 USDT in a USDT pool and 100 BTC in a BTC pool. Across a mixed book, any non-zero value is almost certainly wrong for at least one pool. Leave it at 0 unless every pool shares a denomination.

Route early exits to an admin queue instead of settling them immediately.

The withdraw endpoint has always treated a missing key as approval required, but the settings screen used to draw the same key as off. Because the settings form saves only the keys you actually change, an operator who opened this tab, agreed with what they saw and saved wrote no row at all — so the switch read "off" while the platform behaved as "on", and early exits piled up in PENDING_WITHDRAWAL waiting for a decision nobody knew they owed.

The screen was corrected to on, which is what the platform was already doing. Nothing changed about how any existing installation behaves.

If you want early exits to settle without review, turn this switch off and save — or leave it on and use the auto-approve thresholds below, which release the small or the long-waiting ones for you.

What the two positions mean:

On — an exit requested before endDate becomes a PENDING_WITHDRAWAL position and waits for an admin to approve or reject it. Rewards keep accruing while it waits. The exit fee is priced from the request date, not from your decision.
Off — an early exit settles in the same request, charging the pool's early-withdrawal fee. This is what turns a short-lock pool into a flexible product.

Either way, a withdrawal requested after the lock has expired settles immediately with no fee and never enters the queue.

Auto-approve: the middle ground

Reviewing every early exit and reviewing none are not the only two options. Both keys below are numbers, and 0 means off — including an absent row. They are read as numbers rather than tested for truthiness on purpose: settings are stored as text, and the string "0" is truthy.

Settle an early exit without review when the position is below this amount. 0 disables it.

Release an early-exit request nobody has answered after this many hours. 0 disables it.

Below the amount. An early exit for strictly less than the threshold settles in the same request. A position exactly at the threshold still queues. The figure is compared against the position's amount in whatever the pool is denominated — so on a mixed book, any non-zero value is almost certainly wrong for at least one pool, the same caveat that applies to the minimum-withdrawal amount above.

After the hours. A request that has sat unanswered for longer than this is released by the earnings cron, so a queue you stop working drains itself instead of stranding principal. It is the safety net for the operator going on holiday, not a substitute for working the queue.

Both paths settle the position as an early WITHDRAW, so the pool's earlyWithdrawalFee is charged exactly as it would be if you had approved the request by hand. If you want early exits to be free, set the pool's fee to zero — do not reach for auto-approve expecting it to do that.

A position whose lock has already expired is never an early exit and is never charged, whichever of these is set.

What no setting controls

Worth stating explicitly, because operators look for these:

Per-pool overrides. APR, fees, lock period, earning frequency and auto-compound are pool fields, not settings. The settings above only pre-fill the creation form.
A reward budget or cap. Nothing limits total rewards paid. Your exposure ceiling is each pool's availableToStake, expressed in principal.
Where the yield comes from. There is no external provider integration to configure. The platform pays from the Super Admin treasury and records each payout as a platform loss.
Claim expiry. Unclaimed rewards never expire. They survive completion of the position and remain a liability on the Overview screen until claimed.
Partial withdrawals. Not configurable because not implemented.

Verifying a change took effect

Settings are cached and broadcast to every process, so a save propagates without a restart. To confirm behaviour rather than display:

Save the tab deliberately — toggle a field, save, toggle it back, save again. This forces a real database row for every key on the tab.
Watch the next cron run at /admin/system/cron. The staking task logs which mode it chose: "Automatic earnings distribution is disabled" or "Outside the configured earnings distribution hour" appear in its output when either gate suppresses periodic accrual.
Test a withdrawal with a throwaway position in a short-lock pool. If it lands in PENDING_WITHDRAWAL, approval is on; if the principal appears in the wallet immediately, it is off.

See Platform settings for how settings are stored and which keys are Super-Admin protected.