Staking v6.2.0

Release Date: August 12, 2026 Tags: WITHDRAWALS, FEES, AUTOMATION, ACTIVITY-LOG, AUDIT, SETTINGS, DATABASE, ACCESSIBILITY, BUG-FIXES

Overview

The early-withdrawal queue is the centre of this release. There was no way to say no to a request — an operator could only approve it, or cancel the position, which returns the principal and forfeits every reward the staker had earned. Approving was not much better: the early-exit fee is priced from the day the request was made, so a request that sat in the queue until the term ran out was still billed as an early exit. The staker paid a penalty for the operator's own delay.

Both are fixed, and two settings now let the queue drain itself: auto-approve anything under an amount you choose, and auto-approve anything nobody has answered within a number of hours you choose.

The activity feed has also been missing every reward the scheduled run paid, on any install created before the audit column allowed a system actor — so the feed listed administrators and nothing else. The database column cannot be repaired by a restart, so the repair ships as part of pnpm updator.

Requires Core v6.6.4.

Update Instructions

pnpm updator

The update runs the database repair for you. It checks before it changes anything, is safe to run on a live database, and is skipped entirely on an install without the staking addon.

Restart the backend afterwards. Reward payouts made before this repair are not backfilled — the rows were never written, so there is nothing to recover.

Both new automation settings ship off, so nothing in your queue starts moving on its own until you set them.

Upgrade Notes

Approving an old request no longer charges the staker for your delay

The early-withdrawal fee is priced from the date the request was made, which is a date inside the lock — so every approval was treated as an early exit no matter when it was granted. A request that waited in the queue past the position's own end date was still charged the penalty, even though by then there was no early exit left to approve. The scheduled run and the staker's own withdrawal door both settle that same position fee-free; only the approval door disagreed.

Approving a request whose term has already matured now settles it as a completion, with no fee. Approving one that is genuinely still early is unchanged.

• Fixed approving a pending withdrawal charging the early-withdrawal fee even when the position's term had already ended, so a staker paid for the time the operator took to answer.
• Go and look at your pending withdrawal queue before updating. Anything in it that has passed its end date was going to be charged a penalty and now will not be — and any request you have already approved after its end date was charged one. The audit trail records these as "Admin approved a withdrawal request whose term had already matured" from this release onward.

Withdrawal approval was on while the panel said it was off

The staking settings panel drew Require withdrawal approval as off, and the backend treats an unsaved setting as on. So on an install that had never saved that panel, an early withdrawal was routed to administrator review on a screen that showed nobody was reviewing — the request simply waited.

The panel now shows what the backend actually does. Nothing about the behaviour has changed.

• Fixed the withdrawal-approval switch showing off while early withdrawals were being held for approval.
• Check Staking → Settings for pending withdrawal requests if customers have reported an early withdrawal that never completed.
• Set the switch explicitly if you want early withdrawals to complete without review. Saving the panel is what makes the setting real.

Added

Declining a withdrawal request, without taking the staker's rewards

There was no decline. The bulk control on the positions screen offered Completed and Cancelled, and an operator who wanted to refuse an early exit had only Cancelled — which returns the principal and forfeits every unclaimed reward the staker had earned. Refusing a request and confiscating the rewards are not the same decision, and the interface could only express the second one.

• Added Decline to the positions screen and to the bulk status control. The position simply resumes its lock: nothing is credited, nothing is forfeited, and no fee is charged.
• Added an optional reason on a decline, which is delivered to the staker with the notification telling them their request was refused and their position is still active. The notification is sent only after the change has committed, so a staker is never told about a decline that did not happen.

Two ways to let the queue drain itself

Both ship off, and both live in Staking → Settings.

• Added Auto-approve withdrawals below an amount you set. An early exit for less than that figure settles immediately instead of queuing; everything else still waits for you. It waives the review, not the fee — the pool's early-withdrawal fee is charged exactly as it would be on an approval.
• Added Auto-approve withdrawals after a number of hours. A request nobody has answered within that window releases itself on the next scheduled run, as a normal early exit with the normal fee. A request that outlives its own end date is the other case entirely and settles fee-free, as above.
• Added a distinct notification for an automatically released request, naming the amount returned and the fee charged. It no longer tells the staker their term matured, which is what the maturity notice said and was not true of these.
• Leaving both at zero keeps today's behaviour: every early exit waits for an operator.

Changed

A bulk action now says which positions failed and why

The bulk status control reported a bare count — "3 position(s) updated" — while silently dropping the rows it could not change. The reasons were already being worked out; they simply were not being said.

• Changed the bulk positions response to name each position it could not update and the reason, alongside the count that succeeded.

Fixed

Every reward the engine paid was missing from the activity feed

The scheduled run logs each position it credits so the feed can answer who paid it. Those entries name the system as the actor, and on installs created before that was permitted, the database refused each one — logging "Column 'userId' cannot be null" once per position, on every run.

No money was affected: the entry is written on a best-effort basis precisely so that an audit failure can never roll back a payout. What it cost was the record. The activity feed showed administrator actions and nothing else, while the engine that moves most of the money was invisible in it.

It could not fix itself, either. The platform's schema sync compares a column against its own recorded fingerprint rather than against the database, and the fingerprint was updated when the model was changed — so the column counted as already correct on every boot afterwards, and no restart, cache clear or forced sync would have touched it.

• Fixed the activity feed recording nothing from the scheduled reward run, on every install created before the audit column allowed a system actor.
• Added the repair to pnpm updator, since the schema sync could never apply it. It is idempotent, recovers from a half-finished earlier attempt, and skips installs that do not have the addon.

Two staking pages declared a second main region

The pool and position pages each drew their own main content region inside the one the extension already provides, so those documents had two. A screen reader was offered two main content targets on the same page. The element carried no styling, so nothing about the layout changes.

• Fixed the staking pool and position pages nesting a second main landmark inside the extension's.