What Regen Ledger earns today, read from every transaction.

The windows, with their heights and block times

How the fee is read. Every transaction carries its fee in auth_info.fee.amount; that is what is summed, per denom, for every transaction whose height falls inside the window. A failed transaction still paid, because the fee is taken before the messages run, so failed transactions are counted too (51 of 41,939 in the 90-day window). A node can also hand back a transaction whose body it cannot decode; that transaction is counted with no fee, and the count is stated here and in the JSON for every window so an undercount cannot hide: the 90-day window holds none. A month here is 365.25 divided by 12 days.

Fee denoms seen in the 90-day window

Every message type in the window

How a fee is attributed to a message. A transaction pays one fee for every message it carries. Here that fee is divided equally across the transaction's messages and each message's share is added to its type, so the attributed column sums to the window's total, and the share-of-fees column on the page above is that attributed figure over the window's total. A transaction carrying two types is counted once under each of them, so the transaction column does not sum to the window's total; the fee columns do. The median fee per transaction is the whole fee of the transactions carrying that type, which is what a person or an agent actually paid to get that act onto the ledger. The gas price is the fee over the gas the transaction asked for, in uregen per unit of gas; across all 41,939 transactions the median was 0.0657 uregen per unit of gas. The node's own minimum gas price is not served by the public LCD, so the observed price is the only one stated.

The validator set, in full

How the split is read. The community tax is /cosmos/distribution/v1beta1/params at this height: 17.00%. Fees times the tax is what reaches x/protocolpool; fees times one minus the tax is the validator set's gross, distributed by bonded stake, of which each operator keeps its commission and the rest goes to its delegators. The continuous fund created by #66 takes 15.00% of the pool's inflow and sends it to a keyless address, which is the burn. Monthly figures are the trailing-30-day run rate.

The 28-day epochs behind the trigger answer

Two nodes, counted against each other

The second node. https://regen-api.polkachu.com, whose block store starts at height 27,420,001. Its first page of the since-#74 window (100 transactions) carries the same transaction hashes and the same fee sum as this build's.

Reconciled with the validator floor's own measurement. The floor draft measured 0.3605 REGEN reaching the pool between heights 28,650,946 and 28,669,862 by reading the pool's balance at both heights. This build sums the fees paid in those blocks: 2.12 REGEN, times the community tax is 0.3604 REGEN, a gap of 0.0001 REGEN. The floor module measured the pool's balance change (plus what the #66 fund pushed out) between two heights. Fees paid in block b reach the pool at the start of block b+1, so the fees that fall inside a balance delta from height A to height B are those of blocks A to B-1; that is the window summed here, times the community tax. Run live at this build: the floor module read 0.3546 REGEN over blocks 28,777,711 to 28,797,711 (about 99 REGEN a year, burn share observed 14.94%); the fee sum times the tax over the same blocks is 0.3546 REGEN, a gap of 0 REGEN.

Every number, the call that returns it

Add the header x-cosmos-block-height: 28797712 to any parameter call below and it answers at this page's height. The transaction calls are addressed by height range and need no header.