Angebot

Verwenden Sie diese Seite, um rand_getSupply richtig zu lesen und die Emission nachzuvollziehen: woher RAND kommt, wohin es geht und welche Identität das Angebot einer abgeschirmten Chain exakt macht, obwohl niemand ihre Notes aufsummieren kann.

Woher RAND kommt und wohin es geht

Eine abgeschirmte Chain kann ihr eigenes Geld nicht summieren: Der Wert einer Note liegt in ihrer Commitment verborgen. Öffentlich ist jede Überschreitung der Pool-Grenze. Es gibt fünf Arten, auf einer Chain mit Programm-Vaults (RPL-2, Chain 20) sieben:

Auf einer Chain, deren Genesis tokens.burn_registration_fee setzt, wie bei Chain 20, verlässt auch die registration_fee von 1 RAND einer Token-Registrierung den Pool über burned, geht aber in keinen Register-Eintrag ein: Sie wird vernichtet, und der Proposer behält nur die Bundle-Basisgebühr.

Neben dem Pool steht das Validator-Register, das Beträge im Klartext hält, weil das Konsensgewicht öffentlich sein muss. Stake im Register ist echtes RAND: Er kann entbunden und wieder in eine Note ausgezahlt werden. Auf Chain 20 sind die Programm-Vaults ein zweiter öffentlicher Bestand daneben: RAND, das ein Invoke einzahlt, bleibt dort zählbar, bis eine Auszahlung es als Note in den Pool zurückführt.

Auf Chain 20 gibt es keine Block-Rewards und keine Inflation. Die erste planmäßige Emission der Chain ist die Subvention für die Blockaggregation — eine abnehmende Menge neuen RAND pro versiegeltem Block, gezahlt an den Aggregator, dessen Beweis ihn abdeckt — und sie ist auf Chain 20 nicht aktiv (Proofs). Chain 20 ist eine neue Chain, live seit 2026-10-01 um 06:17 UTC, abgespalten von Chain 19 (fullnode v0.6.8, ein Hard Fork). Ihr Genesis hat 31.184,243719258 RAND ausgegeben: 26.000 als Stake auf die 26 Genesis-Validatoren verteilt und 5.184,243719258 in sieben Einzahlungs-Notes, den Guthaben der sieben Operator-Wallets, die von Chain 19 übernommen wurden. Was andere Wallets auf Chain 19 hielten, etwa 519,9 RAND (Faucet-Mints an zugelassene Empfänger, Zahlungen an Nutzer), wurde nicht übernommen, da eine Note ohne die Adresse ihres Eigentümers nicht neu erzeugt werden kann; ebenso wenig 0,499 RAND nicht abgehobener Validator-Rewards. Zwei weitere Genesis-Notes, insgesamt neun, tragen die 99 zUSD der Bridge (10 und 89), die kein RAND sind und außerhalb dieser Prüfung liegen. rand_getSupply liest auf Chain 20 genesis_deposited 5.184.243.719.258 Einheiten und invariant_holds: true (Höhe 3.037, 2026-10-01). Chain 19, am selben Tag aus einem Snapshot von Chain 18 bei Höhe 141.935 abgespalten, hat 31.294,644359629 RAND ausgegeben: dieselben 26.000 als Stake und 5.294,644359629 in sieben Notes, daneben eine Note über 10 zUSD. Jeder seitherige Faucet-Mint erhöht den ausgegebenen Betrag, und jede verbrannte Registrierungsgebühr verringert ihn. Chain 15, abgespalten am 2026-09-26, hat im Genesis 23.000 RAND ausgegeben, 18.000 als Stake auf 18 Validatoren und 5.000 in fünf Notes; ihre acht späteren Validatoren haben aus bestehenden Notes gebondet, was nichts ausgegeben hat.

Tokens liegen außerhalb dieser Prüfung

Die obigen Überschreitungen gehören zu RAND. Ein RPL-Token, ob gebridged oder nativ, überschreitet nie die RAND-Grenze: Der Asset-Index 0 ist für RAND reserviert und die Token-Registry vergibt ihn nie, sodass ein BridgeAttest, ein TokenMint oder der anfängliche Mint einer Registrierung stets eine Note eines anderen Assets einzahlt und das burn_a eines BridgeBurn oder TokenBurn stets eine solche vernichtet (über burn_a verbranntes RAND wird abgelehnt). fees_paid und burned werden allein aus fee und burn_r eines Bundles gezählt, und eine Token-Überweisung innerhalb des Pools bewegt gar keinen Zähler, da ihr Asset nicht einmal öffentlich ist. Auf Chain 20 kann ein Invoke über burn_a auch einen Token aufnehmen: in den Vault des Programms (deposit), was sein Angebot unverändert lässt, oder vernichtet (burn), nur für den eigenen Token des Programms. Die Gebühren-Notes der Bridge (Chain 20, 10 bps jeder zUSD-Einzahlung und -Verbrennung, an eine Treasury-Adresse) sind zUSD, niemals RAND: ausgegeben und gedeckt, sodass sich die Deckung einer Einzahlung und das Angebot um den Bruttobetrag bewegen und die einer Verbrennung um amount − fee sinken. Das eigene Angebot eines Tokens ist die öffentliche Zählung der Registry: rand_getTokenSupply liefert total_supply und, für einen gebridgten Token, den locked-Betrag jeder Deckung; diese summieren sich zu ihm (RPL tokens).

Die Prüfidentität

Sechs monotone Zähler in Einheiten (1 RAND = 10⁹), zwei, die erfassen, was vernichtet wurde, und auf Chain 20 zwei für die Programm-Vaults:

pool_value     = genesis_deposited + faucet_minted + withdraw_deposited + program_rand_out − fees_paid − burned
register_total = Σ over the register of (stake + pending + rewards)
total_supply   = pool_value + register_total + program_rand_held
issued         = genesis_deposited + genesis_staked + faucet_minted

invariant:       total_supply == issued − slashed − registration_fees_burned

pool_value ist das, was hineinkam, abzüglich dessen, was hinausging — dieselbe Zahl wie die Summe der Notes, die niemand berechnen kann. Die Basisgebühr von 0,001 RAND eines Withdraw ist keine Überschreitung: Sie wandert von einer Register-Zeile in die des Proposers, und nur die Note hat die Grenze überschritten. Ist invariant_holds falsch, so ist das ein Konsensfehler oder eine beschädigte Datenbank, niemals ein zulässiger Zustand. Die beiden Programm-Terme sind auf einer Chain ohne Programm-Vaults null, die Identität ist dort also die von Chain 19. Ein Genesis-Abschnitt vesting, den noch keine Chain hatte, würde auf dieselbe Weise ein drittes öffentliches Register hinzufügen (JSON-RPC).

Verfolgt über einen Bond und ein Withdraw von 1.000 RAND auf einer Chain, die 2.000 eingezahlt und 4.000 gestakt hat:

Lesen der Werte

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"rand_getSupply","params":[]}'

{ "height": 1998,
  "genesis_deposited": "2000000000000", "genesis_staked": "4000000000000",
  "faucet_minted": "0", "withdraw_deposited": "999999000000",
  "fees_paid": "1000000", "burned": "1000000000000",
  "slashed": "0", "registration_fees_burned": "0",
  "pool_value": "1999998000000", "register_total": "4000002000000",
  "total_supply": "6000000000000", "invariant_holds": true }

Jeder Betrag ist ein Dezimal-String in Einheiten, weil eine JSON-Zahl jenseits von 2⁵³ keine exakte Ganzzahl ist. Das vollständige Objekt enthält mehr Felder als hier gezeigt, darunter das Paar faucet_epoch und faucet_minted_in_epoch des Faucets pro Epoche, das Chain 20 gegen sein Budget prüft, program_rand_out und program_rand_held (seit v0.6.8) sowie vier vesting_*-Zähler, die auf Chain 20, deren Genesis keinen vesting-Abschnitt hat, "0" lesen (JSON-RPC). Der Explorer liefert dasselbe Objekt unter GET /supply und die Kennzahlen unter GET /stats.

Wie exakt es ist

Für alles, was die Chain selbst getan hat, sind die Zähler exakt: Jeder wird in dem Codepfad erhöht, der die Aktion anwendet, aus den eigenen öffentlichen Feldern der Aktion.

Zwei Einträge beruhten bisher auf einer Behauptung, und Chain 14 macht beide zu Prüfungen (Audit v3, POOL-1):

• Ein Faucet-Mint trägt die Öffnung der Note. Neben cm und amount veröffentlicht die Aktion pk, time und r. Die Zulassung berechnet die Commitment von (pk, no sender, amount, asset 0, time, r) neu, weist eine Abweichung mit the mint's commitment does not open to its published note and amount zurück und hält time innerhalb des Bundle-Fensters. Der Minter signiert alle sieben Felder unter der Domain rand-mint-2. Zuvor konnte ein Validator einen Betrag veröffentlichen und eine Note mit einem anderen Wert versiegeln. Der Preis dafür: Der Eigentümer pk einer Faucet-Note ist öffentlich, ebenso wie die Auszahlung bei einem Withdraw; die Parameter von rand_mint bleiben unverändert.
• Auch eine Genesis-alloc-Note trägt ihre Öffnung. Auf einer Chain mit einem tokens-Abschnitt hat jede Zeile die Form { cm, envelope, amount, opening: { pk, time, r } }. Ein Node berechnet die Commitment neu, bei Asset 0, sofern die Öffnung nicht das asset eines gelisteten Tokens nennt, und weist eine Genesis-Datei zurück, deren cm nicht übereinstimmt. Nur Zeilen mit Asset 0 zählen zu genesis_deposited. Eine undurchsichtige cm war der einzige Weg, auf dem ein Genesis-Autor eine ungedeckte Note beliebigen Assets in den Pool bringen konnte, ohne dass jemand dies prüfen konnte. Eigentümer und Betrag einer Genesis-Note sind daher von Design her öffentlich, sobald die Datei veröffentlicht ist; privat bleibt nur, wann und wohin sie später ausgegeben wird. rand-node genesis schreibt die Öffnung immer.

Auf einer Chain, die ohne tokens-Abschnitt geschnitten wurde, gilt weiterhin die ältere Regel: genesis_deposited ist die Summe der deklarierten amount-Felder, die der Genesis-Datei vertraut wird. Beide Genesis-Beträge fließen in den Genesis-Hash ein, sodass sich jeder Node in beiden Fällen auf sie einigt.

Die Zähler sind bewusst kein Konsensstatus – der State Root hasht sie nicht –, und rand-node verify --mode quick berechnet jeden von ihnen neu, indem es die Chain erneut abspielt, und meldet eine Abweichung, wenn der gespeicherte Snapshot nicht übereinstimmt.