The Asp Browser is the public face of the Automatic Staking Process (ASP). Every pay period it publishes the staking report (who staked, what they are owed) and the staking requests report (every request and its state), and it drives the fleet that pays the distribution. Its mark — a capital A whose crossbar is a pen stroke — is a signature, because signing the weekly distribution correctly is the one act the whole system exists to perform; wherever you see the mark beside a validator's name, the ASP app cast that vote. This guide is for stakers: how staking works, how to make and read requests, and how to read the reports. (Validators installing the signer app want the app manual — Installing the ASP app, or asp docs.)
The Pay Periods page (the browser home) is the staking report. A pay period is one week; at its close the browser builds a report and the fleet executes the distribution. For each period the report shows, per account:
(see seasoning below);
computed_balance × weight);to its weighted balance;
the net reward.
The period budget is a fixed fraction of the unissued supply: round_half_up(unissued × 112 / 36525) — 16% of the remaining supply per year, spread weekly. From period 140 on, 45% of the budget is withheld to acc://anaf.acme/tokens (ANAF), capped at a 10,000,000 ACME ANAF balance; stakers always receive their share of the remaining 55%. Every projection to nanoACME rounds half-up, and the report matches the executed on-chain distribution to the nanoACME.
At each period's close the fleet submits one IssueTokens transaction paying every reward, and it executes when enough validators sign — 4 of 7 on the staking authority page. While it is pending, the period panel tells the whole story:
and paid its transaction fee. Read from the chain's own record of the initiating signature, never inferred.
the authority page counts toward the threshold; the panel counts exactly those.
cast by the validator's ASP app, automatically. An unmarked vote was signed by a human from their own book. Both count identically; the badge tells you which part of the fleet is running on autopilot.
names them. Votes can be changed: a later vote replaces an earlier one.
acc://ACMEis listed with its memo, its submitter, and its reject count. A duplicate of an already-paid period appears here with a red alarm: it must be rejected, never signed, because at its threshold it would pay everyone twice.
An account's weight multiplies its balance before rewards are split. The class is declared when the account registers:
| Class | Weight | Minimum balance |
coreValidator | 1.30 (13/10) | 50,000 ACME |
coreFollower | 1.30 (13/10) | 50,000 ACME |
stakingValidator | 1.30 (13/10) | 50,000 ACME |
pure | 1.00 | 50,000 ACME |
delegated | the delegate's resolved weight | 1,000 ACME |
An account below its class minimum, or otherwise ineligible for a period, contributes 0 and earns 0 that period. Admitting a validator class (coreValidator, coreFollower, stakingValidator) is a governance act — the signer fleet does not auto-approve it. pure and delegated are self-service.
Delegated staking lets an account stake with a lower minimum (1,000 ACME) by pointing at a delegate — a registered validator. The delegated account inherits the delegate's weight (1.30 if the delegate is a validator) and the delegate takes a delegation fee of 10% of the reward; the staker keeps the net. A delegate that is not a registered staker is unresolved — the account is marked ineligible and earns nothing until the delegate is fixed. Delegated registrations and changes are self-service: no governance approval, only the account owner's signature.
All staking actions go through the request inbox, a data account at acc://staking.acme/requests (in a simulation, <world>/requests). A request is a single data entry, signed by the account's own key book — the book of the account the request names. The inbox is *open*: the chain accepts any signer, and validity is judged by the readers. So:
fleet.
requests report, naming the wrong signer — nothing moves.
The submitter needs credits on their signing page, but there is no multisig and no rejection: if it is well-formed and correctly signed, it will be recognized. Request actions include registering an account (addAccount), deregistering (unstakeAccount), and the account changes below.
New stake does not earn immediately — it seasons (spec §5.1):
deposit made in period M is excluded from M, M+1, M+2 and first earns in M+3. (Rewards are deposits and season the same way.)
amount stops counting immediately at the request, and the tokens are held one period and released in request period + 2 (request in A → held B → released C). The requests report shows this as held with the exact release period and time.
executes immediately; the origin stops counting at once, and the destination receives it as an ordinary deposit that seasons from *its* M+3.
To change a delegated account's parameters — its delegate (changeDelegate), its type (changeType), or its payout destination (changePayout) — file a new register request from the account's own book with the new values. Because delegated staking is self-service, the change is written by the fleet without governance approval. A change of stake amount follows the seasoning rules above: added stake seasons from M+3, reduced stake stops counting at the request.
The Staking Requests page is the request inbox, one row per request, with chain-proven state. Each row shows when it was filed, the period it came in, the period it pays, its status, the action, the detail, and the request id. Statuses:
the row shows the release period and time.
class that is not a staking type, more than one payload in an entry, or filed from an asp signing page (which may sign distributions, never requests).
The report shows everything so a submitter can always see that their request was recognized and what state it is in.