Transaksi dan tindakan

Gunakan halaman ini untuk membina, menghantar atau menyahkod sebuah transaksi: bentuk wayar yang diterima oleh rand_sendTransaction, cara id dikira, senarai penuh tindakan beserta peraturan bundle dan yuran, serta tertib kemasukan yang menentukan ralat mana yang anda terima dahulu.

Transaksi

Transaction { chain_id: u64, bundle: Option<Bundle>, action: Action }

Bundle {                                        // the hidden-asset bundle (since chain 14)
  anchor: Word8, nullifiers: [Word8; 4], commitments: [Word8; 4],
  fee: u64, burn_a: u64, burn_r: u64, burn_asset: u32, time: u32,
  envelopes: [Envelope; 4], proof: Vec<u8>,     // postcard(Proof) of the hidden-asset guest
  auth_commit: Word8, auth_proof: Vec<u8>,      // since chain 17: split authorisation's c and its auth proof
}
Envelope { kem_ct: Vec<u8>, to_receiver: Vec<u8>, to_sender: Vec<u8>, body: Vec<u8> }

Word8 ialah lapan perkataan u32 little-endian, dipaparkan sebagai 64 aksara heks huruf kecil. Bentuk wayar ialah bincode(Transaction) dengan nilai lalai bincode (integer lebar tetap, awalan panjang 8 bait, tag enum u32), dan rand_sendTransaction menerimanya dalam bentuk heks. Tiada tandatangan ke atas transaksi dan tiada medan penghantar: sesebuah bundle mengesahkan dirinya melalui bukti-buktinya (bukti bundle dan, sejak chain 17, bukti auth di sebelahnya), dan tindakan yang bertandatangan membawa tandatangan itu di dalam dirinya sendiri. Perlindungan ulang main ialah set nullifier bagi bundle, nonce bagi setiap validator dalam daftar bagi tindakan staking yang bertandatangan, mint_nonce bagi setiap token untuk TokenMint dan SetAuthority, serta pause_nonce dan list_nonce milik bridge bagi tindakan tadbir urusnya.

Sesebuah transaksi membawa paling banyak satu bundle, dan setiap tindakan yang bukan tanpa-bundle membawa tepat satu. Slot 0–1 bundle membawa aset persendirian dan slot 2–3 membawa RAND, jadi satu bukti memindahkan token dan membayar yuran RAND-nya; pembakaran bridge dua-bundle daripada reka bentuk terdahulu telah dihapuskan: satu pembakaran ialah satu bundle (Notes).

Dompet rand membina semua ini melalui randprotocol_client::wallet::{send, submit}: memilih input, mengambil anchor, mengira saksi (witness) daripada salinan pokok milik dompet itu sendiri, membina output dan menutup keempat-empat sampul, mengambil binding transaksi, membuktikan bundle dan bukti auth, menyemak digest bukti bundle yang diterbitkan, lalu menghantar.

Binding transaksi

Sesebuah transaksi tidak mempunyai tandatangan, dan bukti sesebuah bundle hanya mengikat digest bundle itu sendiri: anchor, nullifier, komitmen, yuran, medan pembakaran, time. Sehingga chain 13, tiada apa-apa yang mengikat bundle yang telah dibuktikan kepada tindakan yang disertainya atau kepada sampul-sampulnya, jadi sesiapa yang melihat sesebuah transaksi boleh mengekalkan setiap bait bukti dan mengubah selebihnya: destinasi BridgeBurn, validator Bond, atau sebuah sampul. Sejak chain 14, setiap bukti bundle dibuat ke atas, dan disahkan terhadap, binding transaksi:

binding(tx) = blake3("rand-tx-bind-1" || bincode(chain_id, bundle', action'))            chains 14 to 19
binding(tx) = blake3("rand-tx-bind-2" || bincode(genesis_hash, chain_id, bundle', action'))  chain 20
                                                                                  as 8 LE u32 words

dengan ' bermaksud setiap rentetan bait bukti bundle digantikan dengan vektor kosong: bundle.proof, sejak chain 17 bundle.auth_proof, dan proof milik Aggregate. Semua yang lain berada di dalamnya: auth_commit, keempat-empat sampul, setiap medan pembakaran, destinasi, validator, penerima, tandatangan, perakuan penjaga (guardian) beserta tandatangan bersama Dilithium2, dan bukti Call itu sendiri. Lapan perkataan itu dibawa dalam segmen input awam bukti, yang digest H_PUB-nya sudah diikat oleh litar, jadi pembetulan ini tidak memerlukan perubahan guest atau litar; nod menjalankan Machine::verify_public(hc_bundle, binding, proof) dan menolak bukti bundle yang mengisytiharkan sebarang ketinggian awam lain (public height not the transaction binding's). Transaction::binding ialah satu-satunya fungsi yang dipanggil dompet sebelum membuktikan dan dipanggil lejar sebelum mengesahkan. Sejak chain 17, bukti auth dibuat ke atas dan disahkan terhadap lapan perkataan yang sama, jadi ia juga tidak boleh dipindahkan ke transaksi lain.

Chain 20 mengikat hash genesis. Sehingga chain 19, binding, dan mesej bertandatangan bagi tindakan tanpa-bundle, hanya merangkumi id chain, jadi dua chain yang berkongsi id chain (pemotongan semula, salinan persendirian) akan menerima bukti dan tandatangan antara satu sama lain. Genesis chain 20 menetapkan binding_domain: 1 (v0.6.8, audit v6 BIND-1; crates/randprotocol-core/src/types/binding.rs). Hash genesis kemudian mendahului setiap preimej di bawah tag yang dinaikkan satu versi: rand-tx-bind-2 dan rand-call-bind-2 bagi kedua-dua binding, dan begitu juga bagi mint faucet (rand-mint-3), Unbond dan Withdraw (rand-unbond-2, rand-withdraw-2), mesej mint dan autoriti RPL (rand-rpl-mint-2, rand-rpl-authority-2), tindakan aggregator dan mesej tadbir urus bridge. Pendaftaran validator pada chain sedemikian sentiasa mesej v2 (genesis, chain, alamat, bayaran keluar). Tiada apa yang dibuktikan atau ditandatangani untuk satu chain disahkan pada chain lain, walau apa pun id chain-nya. Perkataan binding ialah input awam, jadi tiada kunci guest atau verifier yang berubah. Dompet yang lebih lama daripada v0.6.8 masih membuktikan terhadap bentuk id chain dan ditolak pada chain 20. rand_getLimits dan rand_status menyediakan binding_domain (1 pada chain 20, 0 tanpa medan itu).

Di bawah genesis hardening_v6 (chain 16 hingga 20), bukti sesebuah Call turut diikat, melalui digest kedua yang dibina dengan cara yang sama di bawah domainnya sendiri, dengan bukti call dikosongkan di samping bukti-bukti bundle:

call_binding(tx) = blake3("rand-call-bind-1" || bincode(chain_id, bundle', action''))   as 8 LE u32 words

Pada chain 20, tag ialah rand-call-bind-2 dan hash genesis mendahului preimej, seperti di atas. Bukti Invoke diikat dengan cara yang sama, dengan peralihan yang diisytiharkannya dikekalkan dalam preimej, supaya bukti itu mengikat tepat perubahan keadaan, bayaran keluar dan penerima yang dibawa oleh transaksi.

Bukti call membawa perkataan-perkataan ini dalam segmen input awamnya, selepas input awam masa-deploy program itu jika ada, jadi salinannya yang dilampirkan pada bundle yuran lain tidak akan lulus pengesahan. Kedua-dua binding itu bersarang: dompet memilih nota bagi bundle yuran dan membina transaksi dengan bukti kosong, membuktikan call terhadap binding call, memasukkan bukti itu, dan barulah mengambil binding transaksi lalu membuktikan bundle.

Implikasinya bagi klien: bina keseluruhan transaksi — output, sampul, tindakan — sebelum membuktikan. Dompet yang dibina sebelum fork membuktikan terhadap segmen awam yang kosong dan akan ditolak. Tindakan tanpa-bundle tidak mempunyai bukti untuk diikat dan bergantung pada tandatangan masing-masing. Binding bukanlah id transaksi, yang tidak berubah.

Id transaksi

txid = blake3("rand-txid-3" || bincode(view))

dengan view ialah transaksi yang bait proof bundlenya digantikan dengan blake3(proof) (proof_hash) dan bait auth_proof-nya dengan blake3(auth_proof) (auth_proof_hash, selepas auth_commit, yang masuk sebagaimana adanya), setiap medan lain tanpa perubahan. Domainnya ialah rand-txid-2, tanpa dua medan auth, sehingga chain 16; setiap id transaksi berubah dengan chain 17. Menghash bukti melalui digest membolehkan bundle yang dipangkas (pengagregatan blok, tidak aktif pada chain 20) mengekalkan id yang sama seperti bentuk mentahnya; bundle yang dipangkas mengekalkan bukti auth-nya. Transaksi tanpa-bundle menghash bait-baitnya sebagaimana adanya. Id yang sama menjadi kunci mempool, resit dan setiap carian RPC.

Setiap tindakan

Action ialah enum bincode, tag mengikut tertib pengisytiharan:

MintAuthority = None | Key(PublicKey) | Bridge { backings: Vec<Backing> } | Program(Hash)
InitialMint   { amount: u64, recipient: ShieldedAddress, r: Word8, time: u32, envelope: Envelope }
PqSignature   { index: u8, signature: Vec<u8> }   // one guardian's Dilithium2 co-signature, by set index

Pada chain 20, tag 0 hingga 8, 14 hingga 21, 28 dan 30 hingga 33 boleh digunakan. Genesisnya mempunyai seksyen bridge dengan rules_v2, seksyen tokens, staking.admission_by_vote (tag 28), bridge.rotation (tag 30 hingga 32) dan program_state (tag 33). Tag 22 dan 23 ditolak di situ: di bawah bridge.rotation.needs_possession, sesuatu rotasi mesti dalam bentuk …V2 yang membawa tandatangan setiap kunci baharu itu sendiri. Pada chain 19, yang tidak mempunyai mana-mana seksyen tersebut, tag 0 hingga 8 dan 14 hingga 23 boleh digunakan (chain 14, tanpa rules_v2, menolak 22 dan 23). SlashEquivocation memerlukan seksyen staking.slashing, dan seksyen chain 20 ialah null. Lima tindakan pengagregatan memerlukan seksyen aggregation, yang tidak ada pada chain 20 (binaan enggan bermula pada genesis yang membawanya sehingga pengagregatan diukur semula). Nod menolak semua tindakan ini pada pintu semakan sebelum sebarang semakan lain, tetapi tindakan-tindakan itu masih menduduki tag bincode masing-masing, jadi pengekod yang menetapkan nombor tag secara tegar mesti mengiranya. Pengagregatan didokumenkan sebagai akan datang dalam Proofs. Empat tindakan vesting genesis (tag 24 hingga 27, dalam binaan sejak v0.5.11) memerlukan seksyen vesting, yang tidak pernah dimiliki oleh mana-mana rantaian, termasuk chain 20, dan ditolak semasa kemasukan tanpanya. Tag 28 hingga 33 baharu dalam v0.6.8 dan ditambah paling akhir, supaya sejarah setiap rantaian terdahulu masih dapat dinyahkod.

Empat tindakan RPL (tag 14 hingga 17) mendaftar token, mencetak lebih banyak token yang diberi kuasa oleh Key, menyerahkan atau melepaskan kuasa pencetakannya, dan membakar pegangan; RegisterToken yang menamakan kuasa Bridge atau Program ditolak. Tiada tindakan pemindahan token: pemindahan token ialah None, tidak dapat dibezakan daripada pembayaran RAND. Lihat RPL tokens. Empat tindakan tadbir urus bridge (tag 18 hingga 21) ialah penjedaan pencetakan, pengangkatannya, serta penyenaraian token yang dijambatankan atau sokongan tambahan selepas genesis. PauseMints ditandatangani oleh kunci jeda genesis, yang hanya boleh menjeda; tiga yang lain memerlukan kuorum penjaga Dilithium2 (PQ). BridgeAttest turut membawa kuorum sedemikian, di samping kuorum ECDSA-nya. Tag 22 dan 23, di bawah rules_v2 bridge, menggantikan set penjaga PQ atau kunci jeda, masing-masing di bawah kuorum PQ bagi set semasa dan rotation_nonce bridge. Tag 30 dan 31 melakukan perkara yang sama di bawah bridge.rotation dan turut membawa tandatangan Dilithium2 setiap kunci baharu itu sendiri ke atas mesej rotasi, bukti bahawa kunci itu dipegang; pada chain 20 sesuatu rotasi direkodkan sebagai belum selesai dan berkuat kuasa selepas delay_secs, 86,400 s. CancelRotation (tag 32), yang ditandatangani oleh kunci jeda semasa, menggugurkan rotasi yang belum selesai sebelum ia berkuat kuasa. Lihat Bridge.

AdmitValidator (tag 28) ialah undian set validator untuk menerima kunci baharu: tandatangan daripada validator yang memegang lebih daripada dua pertiga stake, mengikut susunan alamat menaik. Di bawah staking.admission_by_vote (chain 20), Bond yang akan mendaftarkan validator baharu ditolak melainkan alamatnya telah diterima melalui cara ini (Staking). Invoke (tag 33, RPL-2) ialah call yang proof-nya mengesahkan satu transition keadaan program yang diisytiharkan: cell yang dibaca dan ditulis, apa yang dibawa masuk oleh medan pembakaran bundle ke dalam peti besi program, dan nota yang dibayar keluar oleh peti besi itu atau yang dicetak oleh program. Lejar menggunakan transition itu jika setiap bacaan yang diisytiharkan masih sah dan kedua-dua proof disahkan (Programs).

Deploy dan Call ialah transaksi terlindung biasa yang bundle-nya ialah pemindahan kendiri sifar: ia wujud untuk membayar had minimum yuran daripada nota milik pemanggil sendiri, supaya rantaian tidak pernah mengetahui milik siapa nota itu. RAND hanya keluar daripada kolam melalui burn_r — stake Bond, bon RegisterAggregator, deposit Invoke ke dalam peti besi program — dan token hanya melalui burn_a dengan burn_asset menamakannya, pada TokenBurn, BridgeBurn atau Invoke. Setiap tindakan lain tidak membakar apa-apa, dan bundle dengan burn_asset = 0 serta burn_a bukan sifar ditolak di mana-mana.

Susunan kemasukan

Ledger::validate_inner menyemak perkara yang murah sebelum yang mahal, mengikut susunan ini; mempool menjalankan semakan yang sama sebelum menyebarkan, jadi transaksi yang tidak sah ditolak sekali sahaja, di tepi.

1. Had saiz — keseluruhan transaksi ≤ max_block_bytes rantaian; setiap satu daripada empat sampul bundle, dan mana-mana sampul nota yang dibawa oleh tindakan, tepat sebanyak envelope_bytes genesis (1,860 pada chain 20; selebih-lebihnya 2,048 bait pada rantaian tanpa medan tersebut); bukti bundle, bukti auth dan bukti panggilan masing-masing ≤ max_proof_bytes (2 MiB secara lalai, 4 MiB dalam genesis chain 20; ia 8 MiB pada chain 13 hingga 16); sesuatu atur cara ≤ had atur cara rantaian (4,096 perkataan secara lalai, 65,535 dalam genesis chain 20); sampul panggilan ≤ max_call_envelope_bytes (18,432 bait secara lalai, 65,536 pada chain 20); sesuatu perakuan ≤ 16 KiB. Bukti bundle dalam bentuk penanda termeterai (dipangkas) ditolak di sini di luar penyegerakan bentuk termeterai (PrunedFormOutsideSync), sebelum sebarang kerja bukti.
2. ID rantaian sepadan.
3. Bentuk dan lantai yuran — tindakan tanpa bundle tidak membawa bundle dan semua yang lain mesti membawa tepat satu; check_burn_shape menetapkan medan pembakaran yang mana, antara tiga, boleh ditetapkan oleh tindakan: TokenBurn atau BridgeBurn membakar asset dan amountnya sendiri melalui burn_asset dan burn_a, Bond atau RegisterAggregator membakar jumlahnya melalui burn_r, dan setiap tindakan lain tidak membakar apa-apa; fee ≥ fee_floor(action). Pada rantaian yang mempunyai seksyen gas (chain 20), lantai Call atau Invoke pada langkah ini ialah peraturan gas pada had yang diisytiharkan sebanyak 1, BUNDLE_BASE + gas_price + byte_price × ⌈bytes / 1024⌉ ke atas bukti dan sampul inputnya, yang diketahui sebelum sebarang pengesahan.
4. Sauh — salah satu daripada 1,024 akar hujung blok terakhir pada chain 20, yang genesisnya menetapkan proof_window_blocks: 1024 (v0.6.8); salah satu daripada 256 terakhir pada rantaian tanpa medan tersebut, seperti hingga chain 19.
5. Masa — dalam lingkungan [height − 1024, height] pada chain 20; [height − 256, height] tanpa medan tersebut. Satu nilai genesis menetapkan kedua-dua tetingkap.
6. Nullifier dan komitmen — keempat-empat nullifier berbeza dan tiada yang telah dibelanjakan; keempat-empat komitmen berbeza dan tiada yang sudah menjadi daun.
7. Semakan tindakan — faucet diaktifkan, mint berada di bawah had dan ditandatangani oleh validator, dan pada chain 20 menamakan penerima dalam senarai benar staking.faucet_recipients genesis, muat dalam faucet_budget_per_epoch bagi epoch tersebut dan ditandatangani oleh validator dalam senarai staking.faucet_minters genesis (peraturan kesahan sejak chain 16); mint atau deposit pada atau melebihi 2⁶³ ditolak pada setiap rantaian; atur cara dapat dinyahkod; atur cara wujud; peraturan staking (pendaftaran hadir tepat apabila validator tidak diketahui, nonce, tandatangan, stake yang mencukupi); peraturan tersendiri jambatan bagi BridgeAttest dan BridgeBurn serta bagi tindakan jeda dan penyenaraian; peraturan RPL bagi empat tindakannya, termasuk yuran pendaftaran; pada chain 20, kuorum undian kemasukan, dan bagi Invoke bentuk peralihan, bacaan yang diisytiharkan terhadap sel yang disimpan, perlindungan peti simpanan bagi setiap bayaran keluar dan yuran sel. Kesemuanya dijalankan sebelum bukti bundle, jadi transaksi yang tidak dapat dilaksanakan tidak menanggung kos pengesahan STARK. Di bawah hardening_v6 (chain 16 hingga 20), dua lagi penolakan berada di sini: Deploy atur cara yang tidak mungkin dipegang oleh mana-mana panggilan (ProgramUncallable), dan bukti bundle atau panggilan yang pengepala atau transkripnya membawa medan yang tidak akan ditulis oleh prover yang jujur (non-canonical proof: …), ditolak sebelum mana-mana bukti disahkan. Sejak v0.6.8, bukti yang pengepalanya mengisytiharkan darjah melebihi had jadual tertinggi ditolak dahulu di bawah keputusan yang sama (audit v6 ZKV-4), sebelum semakan menelusurinya.
8. Digest bundle — pada rantaian kebenaran terpisah (setiap rantaian sejak 17), medan auth disemak dahulu: bundle tanpa bukti auth ditolak, c yang diterbitkan oleh bukti auth (dibaca, belum disahkan) mesti sama dengan auth_commit, dan pada chain 20 bukti auth mesti mengisytiharkan GAS_LIMIT tepat 1,279. Kemudian lejar mengira semula digest medan terbitan bundle, termasuk auth_commit, dan ia mesti sama dengan apa yang diterbitkan oleh bukti. Pada chain 20, bukti bundle juga mesti mengisytiharkan GAS_LIMIT tepat sebanyak bundle_gas_limit genesis, iaitu 20,479.
9. Bukti bundle — Machine::verify_public terhadap hc_bundle yang dipaku genesis dan pengikatan transaksi. Pada rantaian kebenaran terpisah, bukti auth disahkan seterusnya, terhadap hc_auth yang dipaku genesis dan pengikatan yang sama.
10. Bukti panggilan dan yuran peringkatnya — bagi Call atau Invoke, pengepala bukti dipaku dahulu (peringkat selebih-lebihnya 14, jadual keccak selebih-lebihnya 2¹², jadual sha256 selebih-lebihnya 2¹³, ketinggian atur cara yang dideploy, dengan lantai 2⁷ baris di bawah hardening_v6, dan pada chain 20 GAS_LIMIT yang diisytiharkan tidak melebihi siling pengepala gas_max), kemudian STARK panggilan terhadap code_hash atur cara dan, di bawah hardening_v6, pengikatan panggilan transaksi. Yuran disemak paling akhir, kerana ia hanya dapat diketahui setelah bukti dinyahkod: pada chain 20 fee ≥ BUNDLE_BASE + gas_price × GAS_LIMIT + byte_price × ⌈bytes / 1024⌉ pada harga yang berkuat kuasa, ditambah cell_fee bagi setiap sel yang dicipta untuk Invoke (Yuran); pada rantaian tanpa seksyen gas fee ≥ BUNDLE_BASE + call_fee(tier).

Ralat dikembalikan daripada rand_sendTransaction sebagai kod -32000 beserta sebabnya: nullifier already spent, anchor is not one of the last 1024 roots (256 pada rantaian tanpa proof_window_blocks), time 12 is outside [476, 1500], fee 1000000 below minimum 2000000, the bundle's digest is not what its proof published, invalid bundle proof: …, unknown program …, already in mempool, conflicts with a pending transaction over <nullifier>, faucet is disabled on this chain, dan sejak chain 14 the bundle burns asset 2 on an action that burns no token, a burn of 5 is not allowed on this action, the bundle burns 399, not the 400 the action declares, wrong mint nonce: expected 1, got 0, wrong token index: expected 3, got 2, sejak chain 17 this chain requires an auth proof on every bundle (genesis hc_auth) dan the auth proof publishes a different commitment than the bundle's auth_commit, dan pada chain 20 envelope is 1348 bytes, this chain requires exactly 1860 dan bundle proof declares gas limit …, this chain requires exactly 20479. Penerimaan bukanlah pengesahan komitmen: buat pengundian rand_getTransaction sehingga ia mengembalikan blok.

Blok yang mengandungi sebarang transaksi tidak sah adalah tidak sah. Mempool mengindeks setiap nullifier dan komitmen yang belum selesai dan menolak konflik secara terus, jadi dua bundle yang membelanjakan nota yang sama tidak pernah berkongsi satu blok.

Saiz

Enam baris pertama ialah pengekodan sejak chain 18: medan memo menambah 512 bait kepada setiap sampul, dan kebenaran terpisah menambah 40 bait kepada bundle sebelum bait bukti auth itu sendiri. Maka pindahan terlindung di atas wayar adalah kira-kira 2.88 MB sejak chain 18, termasuk chain 20, hampir keseluruhannya bukti, apa pun aset yang dipindahkan: kira-kira 1.5 MB bukti bundle dan 1.37 MB bukti auth. Ia kira-kira 1.43 MB hingga chain 15, dengan satu bukti. Blok dihadkan kepada 2,000 transaksi (MAX_BLOCK_TXS) dan kepada max_block_bytes rantaian bagi bait transaksi, kedua-duanya peraturan konsensus: 4 MiB secara lalai (MAX_BLOCK_BYTES), yang memuatkan satu pindahan sedemikian, dan 20 MiB dalam genesis chain 20, yang mempunyai ruang untuk tujuh. Genesis dengan hc_auth mesti menetapkan max_block_bytes sekurang-kurangnya tiga kali max_proof_bytes ditambah 1 MiB, kerana transaksi boleh membawa tiga bukti (bundle, auth, panggilan), jadi lalai 4 MiB ditolak di sana. Pengagregatan peringkat blok ialah penyelesaian yang telah dijadualkan; lihat Bukti.

Membacanya semula

rand_getTransaction(hash) mengembalikan null sehingga transaksi dikomit, kemudian kedudukan bloknya dan medan awam sahaja:

{
  "height": 192, "index": 0, "block_hash": "63f6…08",
  "tx": {
    "hash": "4f2c…e7", "chain_id": 20,
    "bundle": {
      "anchor": "6b1d…c4",
      "nullifiers": ["8c04…d1", "5e77…20", "03aa…6f", "e19b…42"],
      "commitments": ["2a9f…07", "b310…88", "77c1…0e", "5d20…b3"],
      "fee": "1000000", "burn_a": "0", "burn_r": "0", "burn_asset": 0, "time": 5,
      "proof_len": 1497544, "envelope_len": [1860, 1860, 1860, 1860],
      "auth_commit": "0bab…e8a1", "auth_proof_bytes": 1370827
    },
    "action": { "kind": "none" }
  }
}

Tiada medan from, to, nonce, jumlah mahupun asset dalam sesuatu pemindahan, dan tiada juga dalam blok yang disimpan: nod tidak mempunyai apa-apa lagi untuk disunting. auth_commit dan auth_proof_bytes (panjang bukti pengesahan) wujud sejak chain 17. Bundel sentiasa mempunyai empat slot, termasuk slot dummy, dan pemindahan RAND serta pemindahan mana-mana token RPL kedua-duanya ialah "kind": "none". Setiap jumlah u64 ialah rentetan perpuluhan sejak chain 14 (fee, burn_a, burn_r, amount bagi sesuatu tindakan); indeks, nonce, ketinggian dan panjang kekal sebagai nombor JSON. Jenis tindakan yang lain memaparkan medan awamnya — mint, deploy, call, bond, unbond, withdraw, bridge_attest, bridge_burn, register_token, token_mint, set_authority, token_burn, pause_mints, unpause_mints, register_bridged_token, list_backing, rotate_pq_guardians, rotate_pause_key, empat jenis pengvestan claim_vested, revoke_vesting, bond_vested, unbond_vested, dan sejak v0.6.8 admit_validator, slash_equivocation, rotate_pq_guardians_v2, rotate_pause_key_v2, cancel_rotation dan invoke — seperti yang disenaraikan dalam rujukan JSON-RPC.