اسٹیکنگ

اس صفحے سے کسی چلتی ہوئی چین پر ویلیڈیٹر سیٹ میں شامل ہوں، اسے چھوڑیں اور رجسٹر کو پڑھیں۔ اتفاقِ رائے (consensus) کا وزن عوامی ہونا ضروری ہے، اس لیے ویلیڈیٹر رجسٹر اس چین کا واحد جدول ہے جس میں رقوم کھلے طور پر درج ہوتی ہیں؛ اس کے باوجود اسٹیک ایک شیلڈڈ نوٹ سے نکلتا ہے اور واپس بھی ایک شیلڈڈ نوٹ ہی میں جاتا ہے۔

رجسٹر

ہر اس ویلیڈیٹر کی ایک قطار جس نے کبھی بھی بانڈ کیا ہو، اور ہر قطار اس کے base58 ایڈریس سے پہچانی جاتی ہے:

ValidatorEntry {
    public_key,                  // Dilithium2: signs blocks, and this validator's staking actions
    stake:    u64,               // bonded: the weight an epoch's set gives it
    pending:  Vec<(u64, u64)>,   // unbonding, as (release_epoch, amount), oldest first
    rewards:  u64,               // fees earned as a block proposer, unpaid
    payout:   ShieldedAddress,   // rand1… — where a withdraw pays
    nonce:    u64,               // replay protection for its signed actions
    activation_epoch: u64,       // under a `staking` section: the first epoch this row may be in a set
}

ہر فیلڈ عوامی ہے اور رجسٹر کا ہیش ہر بلاک کے اسٹیٹ روٹ میں شامل ہوتا ہے۔ کوئی قطار کبھی حذف نہیں ہوتی: جو ویلیڈیٹر اپنا پورا اسٹیک ان بانڈ کر دے، اس کی قطار stake = 0 کے ساتھ باقی رہتی ہے۔

ایپوک

epoch(h) = h / epoch_blocks۔ ایپوک e ≥ 1 کا سیٹ ایپوک e − 1 کے آخری بلاک کے وقت کے رجسٹر سے اخذ کیا جاتا ہے: وہ تمام قطاریں جن میں stake ≥ MIN_STAKE ہو، ان میں سے (stake descending, address ascending) کی ترتیب سے سرفہرست MAX_VALIDATORS، پھر انہیں ایڈریس کے لحاظ سے ترتیب دیا جاتا ہے۔ کسی ویو کا لیڈر، کسی بلاک کے ووٹر اور کسی سرٹیفکیٹ کی تصدیق، سب اسی ایپوک کا سیٹ استعمال کرتے ہیں جس سے وہ بلاک تعلق رکھتا ہے۔ اس کے دو نتائج ہیں:

• بانڈ کسی بعد کی حد سے پہلے وزن نہیں بنتا۔ بانڈ فوراً رجسٹر میں درج ہو جاتا ہے، مگر سیٹ صرف کسی حد پر بدلتا ہے: جس چین میں staking سیکشن نہ ہو وہاں اگلی حد پر، اور چین 20 پر اس کے بعد (نیچے)۔
• ان بانڈ سے وزن اگلی حد پر کم ہو جاتا ہے، جبکہ رقم قابلِ نکاسی ہونے کے لیے دو ایپوک انتظار کرتی ہے۔ یعنی ویلیڈیٹر رقم نکال سکنے سے بہت پہلے بلاک تجویز کرنا بند کر دیتا ہے۔

اگر اخذ کیا گیا سیٹ خالی ہو تو پچھلا سیٹ برقرار رکھا جاتا ہے۔ جو نوڈ --validator کے ساتھ شروع کیا جائے اور جس کی کلید کسی موجودہ سیٹ میں نہ ہو، وہ اس وقت تک صرف مشاہدہ کرتا ہے جب تک کوئی ایپوک اسے شامل نہ کر لے، اس لیے جینیسس کے بعد بانڈ کر کے شامل ہونے والے ویلیڈیٹر کو ری اسٹارٹ کی ضرورت نہیں ہوتی؛ rand_status الگ الگ بتاتا ہے کہ is_validator (کلید اس نوڈ پر موجود ہے) اور active_validator (کلید موجودہ سیٹ میں ہے)۔

اسٹیکنگ سیکشن

جینیسس میں ایک staking سیکشن ہو سکتا ہے (fullnode v0.5.4، آڈٹ v4 STAKE-2)۔ اس کے بغیر اوپر کے قواعد ہی سب کچھ ہیں، جیسا کہ چین 14 پر تھا۔ چین 15 کے بعد سے ہر چین میں یہ سیکشن موجود ہے۔ چین 20 میں یہ سوئچ آن ہیں:

"staking": {
  "faucet_budget_per_epoch": "10000000000000", "bond_activation_epochs": 2,
  "max_weight_bps": 3333, "max_stake_entry_bps_per_epoch": 2500,
  "admission_by_vote": true, "registration_v2": true,
  "faucet_recipients": ["rand1…", "…16 wallets…"],
  "faucet_minters": ["<validator address>", "…18 validators…"]
}

اس سیکشن کے تحت فاسٹ کاؤنٹر اور بانڈ کی قطار اسٹیٹ روٹ میں ڈومین rand-state-5 کے تحت شامل کیے جاتے ہیں، اور ویلیڈیٹر لیف rand-validator-leaf-4 ہوتا ہے۔ چین 20 میں متحرک گیس قیمتیں اور RPL-2 پروگرام اسٹیٹ بھی ہیں، جو ان کے بعد شامل کیے جاتے ہیں اور اس کے ڈومین کو rand-state-8 پر لے جاتے ہیں، اور ووٹ کے ذریعے داخلہ اس روٹ کو ایک بار مزید H("rand-state-admitted-1", root ‖ admitted_root) کی صورت میں لپیٹ دیتا ہے۔ چین 15 میں faucet_minters کی فہرست نہیں تھی: وہاں ہر نوڈ فاسٹ کا Mint اپنے پول میں صرف تب رکھتا اور آگے بھیجتا تھا جب اس پر کسی جینیسس ویلیڈیٹر کے دستخط ہوں (MinterNotAllowed، نوڈ پالیسی کے طور پر)، تاکہ جینیسس کے بعد بانڈ ہونے والا ویلیڈیٹر پول کے ذریعے بجٹ ختم نہ کر سکے۔ فہرست کے ساتھ یہی انکار ایک صحت کا قاعدہ (validity rule) بن جاتا ہے۔

تاریخ: چین 15 سے 19 تک admission_by_vote نہیں تھا، اس لیے 1,000 RAND رکھنے والی کوئی بھی کلید رجسٹر ہو سکتی تھی، اور ان چینوں میں داخلے کا بجٹ ایک مقررہ max_stake_entry_per_epoch کے طور پر فی حد 10,000 RAND طے تھا۔ مقررہ عدد ایک ہی جینیسس کے حساب سے طے ہوتا ہے؛ تناسب نئے شامل ہونے والے کو اسٹیک کتنا ہی ہو، ایک جیسے حصے تک محدود رکھتا ہے۔ یہ دونوں فیلڈز بیک وقت مقرر نہیں کی جا سکتیں۔

ووٹ کے ذریعے داخلہ

fullnode v0.6.8 میں نیا (آڈٹ v6، STAKE-2) اور چین 20 پر فعال۔ 1,000 RAND فی کلید کے حساب سے 26 کلیدوں کے ساتھ، سیٹ کا رکاوٹی ایک تہائی تقریباً 13,000 RAND کے خریدے ہوئے اسٹیک کے برابر ہے، اور کچھ بھی سلیش نہیں ہوتا۔ اس قاعدے کے تحت سیٹ خود طے کرتا ہے کہ کون سی نئی کلیدیں رجسٹر ہو بھی سکتی ہیں۔

• ووٹ ایک ایکشن ہے، AdmitValidator { candidate, signatures }، جس کے ساتھ نہ کوئی بنڈل ہوتا ہے نہ فیس۔ ہر دستخط کسی ویلیڈیٹر کا blake3("rand-admit-validator-1" ‖ genesis hash ‖ candidate address) پر Dilithium2 دستخط ہے، اور دستخط ووٹروں کے ایڈریسوں کی صعودی ترتیب میں ہوتے ہیں۔ ووٹروں کے پاس ووٹنگ سیٹ کے وزن کا قطعی طور پر دو تہائی سے زیادہ ہونا ضروری ہے، وہی حساب جو کورم سرٹیفکیٹ کا ہے: چین 20 پر 26 میں سے 18 ویلیڈیٹر۔ ووٹ ایک جینیسس سے بندھا ہوتا ہے اور اسے نانس کی ضرورت نہیں: داخلہ اسی رجسٹریشن میں صرف ہو جاتا ہے جس کی وہ اجازت دیتا ہے۔
• ووٹنگ سیٹ موجودہ ایپوک کے لیے رجسٹر سے خود اخذ کیا گیا سیٹ ہے۔ قطار میں موجود بانڈ اس میں وزن نہیں ہوتا، اور ان بانڈ اسے فوراً چھوڑ دیتا ہے۔ کوئی امیدوار اپنے حق میں خود ووٹ نہیں دے سکتا۔
• داخلہ یافتہ سیٹ اتفاقِ رائے کی اسٹیٹ ہے، جس میں رجسٹریشن کی منتظر زیادہ سے زیادہ 256 کلیدیں ہوتی ہیں (اس سے آگے AdmissionSetFull)۔ rand_getAdmitted اسے فراہم کرتا ہے؛ rand_getLimits.admission_by_vote بتاتا ہے کہ آیا کسی چین کو ووٹ درکار ہے۔

# each voting validator, offline
rand-node admit sign --candidate <registration hex or public key> --key node.key.json --genesis-hash <hash>
# whoever collects the lines
rand-node admit submit --candidate <…> --signature <line> --signature <line> … --rpc http://127.0.0.1:8545

اس کے بعد بانڈ نیچے بیان کردہ طریقے سے آگے بڑھتا ہے۔ rand_getGenesisHash وہ ہیش لوٹاتا ہے جو admit sign کو درکار ہے۔

چار کمانڈز

کون سی بائنری کس ایکشن کی مالک ہے، یہ اس سے طے ہوتا ہے کہ اس پر دستخط کون سی کلید کرتی ہے: بانڈ نوٹس خرچ کرتا ہے، اس لیے یہ والیٹ کی کمانڈ ہے؛ ان بانڈ اور ودڈرا پر ویلیڈیٹر کی Dilithium2 کلید کے دستخط ہوتے ہیں، جو صرف نوڈ کے پاس ہوتی ہے۔

رجسٹر

rand-node register --key node.key.json --payout "$(rand --key payout.key.json address)" --v2 [--rpc http://127.0.0.1:8545]

یہ ویلیڈیٹر کا ایڈریس اور ایک hex Registration پرنٹ کرتا ہے: اس کی پبلک کلید، ادائیگی کا ایڈریس اور ایک دستخط۔ --v2 کے ساتھ، جو چین 20 پر لازمی ہے، دستخط rand-register-2 کے تحت چین کے جینیسس ہیش، چین id، ویلیڈیٹر کے ایڈریس اور ادائیگی کے ایڈریس پر ہوتا ہے؛ اس کے بغیر v1 صورت، یعنی blake3("rand-register" ‖ bincode(chain_id, payout))، استعمال ہوتی ہے جسے چین 20 مسترد کرتا ہے (چین 20 جیسی binding_domain: 1 چین پر رجسٹریشن کا پیغام ہر حال میں v2 والا ہی ہوتا ہے)۔ چین id اور، --v2 کے ساتھ، جینیسس ہیش RPC سے پڑھے جاتے ہیں، اس لیے ایک چین کے لیے دستخط شدہ رجسٹریشن دوسری چین پر مسترد ہو جاتی ہے۔ ادائیگی کا ایڈریس ایک والیٹ ایڈریس ہے، نوڈ کی کلید نہیں، اور یہی وہ واحد فیلڈ ہے جسے بعد کا کوئی ٹاپ اپ تبدیل نہیں کر سکتا۔ یہ hex اس شخص کے حوالے کریں جس کے پاس اسٹیک ہے۔

بانڈ

rand bond <validator base58> <amount in RAND> [--registration <hex>] [--fee <RAND>] [--no-wait] [--cuda]

ایک عام شیلڈڈ ٹرانزیکشن: والیٹ وہی 4-ان-پٹ، 4-آؤٹ پٹ پوشیدہ اثاثہ بنڈل ثابت کرتا ہے جو chain 14 سے ہر ٹرانزیکشن میں شامل ہے، اور اسٹیک کی گئی رقم اس کے RAND برن، burn_r، میں ہوتی ہے۔ لیجر کوئی بانڈ صرف اسی وقت قبول کرتا ہے جب burn_r == amount ہو۔ chain 20 پر بنڈل میں دو ثبوت ہوتے ہیں، جیسا کہ chain 17 سے ہر بنڈل میں رہا ہے: tier-14 بنڈل ثبوت اور اسپینڈ کی (spend key) پر tier-10 اجازت نامے کا ثبوت۔ بطورِ طے شدہ دونوں مقامی طور پر ثابت کیے جاتے ہیں، اور Apple Silicon لیپ ٹاپ پر اس میں تقریباً دو منٹ لگتے ہیں (ثبوت سازی کی میموری)۔ والیٹ کے --prover آپشن کے ساتھ بنڈل ثبوت اس کی بجائے ایک جوڑا ہوا ثابت کنندہ بناتا ہے، جبکہ اجازت نامے کا ثبوت والیٹ کی مشین پر ہی رہتا ہے۔ --registration ٹھیک اسی وقت لازم ہے جب ویلیڈیٹر ابھی رجسٹر میں نہ ہو، اور اگر وہ رجسٹر میں ہو تو اسے مسترد کر دیا جاتا ہے؛ والیٹ پہلے رجسٹر سے پوچھ لیتا ہے۔ chain 20 پر رجسٹریشن والا بانڈ NotAdmitted کے ساتھ مسترد ہو جاتا ہے، جب تک کہ سیٹ پہلے ووٹ کے ذریعے اس کلید کو داخلہ نہ دے چکا ہو (ووٹ کے ذریعے داخلہ)؛ اضافی بانڈ (ٹاپ اپ) کے لیے کسی ووٹ کی ضرورت نہیں۔ رجسٹریشن والا بانڈ کم از کم 1,000 RAND کا ہوتا ہے؛ ٹاپ اپ صفر سے زیادہ کوئی بھی رقم ہو سکتی ہے۔ چین کو صرف یہ معلوم ہوتا ہے کہ اس ویلیڈیٹر کا اسٹیک اتنا بڑھ گیا ہے؛ کن نوٹوں سے ادائیگی ہوئی اور وہ کس کے تھے، یہ منتقلی کی طرح پوشیدہ رہتا ہے۔ کوئی بھی شخص رقم کے سوا کچھ ظاہر کیے بغیر کسی ویلیڈیٹر پر اسٹیک کر سکتا ہے۔

submitted bond 8c3f…e1
  0 RAND out, 1000 RAND burned, 0.999 RAND change, fee 0.001 RAND, anchored at height 412
2nRdFC…: stake 1000 RAND, counting as consensus weight from epoch 69

والیٹ جو ایپوک دکھاتا ہے وہ اگلی حد ہے۔ اس میں فعال ہونے کی تاخیر شامل نہیں: chain 20 پر ایپوک 68 میں کمٹ ہونے والا بانڈ زیادہ سے زیادہ جلدی ایپوک 71 سے وزن بنتا ہے۔ اگر داخلے کا بجٹ، یعنی ہر حد پر فعال وزن کا ایک چوتھائی، ختم ہو چکا ہو تو یہ اس کے بعد بنتا ہے۔

ان بانڈ

rand-node unbond <amount in RAND> --key node.key.json [--rpc …] [--no-wait]

amount کو stake سے pending میں منتقل کرتا ہے، release_epoch = epoch + 2 کے ساتھ، اور نانس میں ایک کا اضافہ کرتا ہے۔ یہ مفت ہے، اس میں کوئی بنڈل نہیں ہوتا، اور اس پر chains 14 تا 19 پر blake3("rand-unbond" ‖ bincode(chain_id, validator, amount, nonce)) اور chain 20 (genesis binding_domain: 1) پر blake3("rand-unbond-2" ‖ bincode(genesis_hash, chain_id, validator, amount, nonce)) کے اوپر دستخط ہوتے ہیں؛ یہ ایک بلاک کے وقت میں کمٹ ہو جاتا ہے۔ rand-node v0.6.8 جس چین سے رابطے میں ہو، اس کے مطابق شکل کا انتخاب خود کرتا ہے۔ اسٹیک سے زیادہ یا صفر رقم کا ان بانڈ مسترد کر دیا جاتا ہے؛ ایک ایپوک میں کئی ان بانڈ ایک ہی pending قطار میں ضم ہو جاتے ہیں۔

نکلوائی

rand-node withdraw <amount in RAND> --key node.key.json [--rpc …] [--no-wait]

جاری شدہ قدر، یعنی rewards اور وہ pending قطاریں جن کا release_epoch آ چکا ہو (سب سے پرانی پہلے)، رجسٹر کے payout پتے پر ایک ڈپازٹ نوٹ میں ادا کرتا ہے۔ اس پر ویلیڈیٹر کے دستخط ہوتے ہیں (chain 20 پر rand-withdraw-2 کے تحت، ان بانڈ کی طرح پہلے genesis ہیش پر)۔ اس میں کوئی بنڈل نہیں ہوتا لیکن یہ مفت نہیں: 0.001 RAND کی بنیادی فیس اس بلاک کے تجویز کنندہ کو جاتی ہے جو اسے لاگو کرتا ہے، اور یہ رقم میں سے کٹتی ہے۔ چنانچہ 1,000 RAND کی نکلوائی سے 999.999 مالیت کا نوٹ بنتا ہے، اور جو رقم بنیادی فیس پوری نہ کر سکے وہ مسترد کر دی جاتی ہے۔ نوٹ کا حساب چین خود کرتی ہے:

cm = H_CM(payout.pk, from = 0, amount − 0.001 RAND, asset 0, time, r)

time کمانڈ چلنے کے وقت ہیڈ کی بلندی ہے (یہ دکھائی جاتی ہے اور دستخط سے بندھی ہوتی ہے)۔ اسے بنڈل ونڈو کے اندر کہیں بھی قبول کیا جاتا ہے (chain 20 پر 1,024 بلاک، جس کا genesis proof_window_blocks مقرر کرتا ہے؛ پچھلی چینز پر 256)۔ r شائع کیا جاتا ہے تاکہ چین کبھی کوئی کمٹمنٹ نیٹ ورک سے نہ لے۔ اس کے بعد ادائیگی وصول کرنے والا والیٹ اسکین کر کے نوٹ ڈھونڈ لیتا ہے، اسے کچھ بتائے بغیر:

rand --key payout.key.json balance      # balance: 999.999 RAND

شمولیت اور علیحدگی

# on the joining validator's machine
rand-node register --key node.key.json --payout "$(rand --key payout.key.json address)" --v2
rand-node run --datadir ./data --key node.key.json --validator --bootstrap /ip4/…/p2p/…
#   it syncs and observes; rand_status says is_validator true, active_validator false

# on chain 20: validators holding more than two thirds of the weight vote the key in
rand-node admit sign --candidate <hex from above> --key <their node.key.json> --genesis-hash <hash>
rand-node admit submit --candidate <hex from above> --signature <line> … --rpc http://127.0.0.1:8545

# on the machine holding the stake
rand bond <validator base58> 1000 --registration <hex>
rand validators                       # the new row, active false until it activates

# from its activation epoch on (on chain 20, three boundaries after the bond at the earliest)
rand-node status                      # active_validator: true

rand-node unbond 1000 --key node.key.json     # out of the set at the next boundary
#   wait two epochs
rand-node withdraw 1000 --key node.key.json    # a note worth 999.999 RAND at the payout address

ان بانڈ کرنے سے پہلے کورم کا حساب جانچ لیں: n ارکان کے سیٹ کو اپنے اسٹیک کے 2/3 سے زیادہ کا آن لائن ہونا ضروری ہے۔ chain 20 پر تمام 26 ویلیڈیٹر ٹھیک MIN_STAKE پر ہیں، اس لیے کوئی بھی ان بانڈ اس نوڈ کو اگلے ایپوک کے سیٹ سے باہر کر دیتا ہے، اور 26 میں سے 18 کا چلتے رہنا ضروری ہے۔ جو ویلیڈیٹر چل رہا ہو مگر ووٹ نہ دے، وہ بھی کورم کے خلاف شمار ہوتا ہے: chain 14 سے ویلیڈیٹر ایسے بلاک پر اپنا ووٹ روک لیتا ہے جو اس کی اپنی گھڑی سے 15 s سے زیادہ آگے ہو، لہٰذا جس ویلیڈیٹر کی گھڑی پیچھے چل رہی ہو وہ کوئی ایرر دیے بغیر ووٹ دینا بند کر دیتا ہے۔ اس پر NTP چلائیں (ویلیڈیٹر چلانا)۔

genesis رجسٹر کو براہِ راست ابتدائی اندراجات دیتا ہے، ہر --validator <key or hex pubkey>,<stake>,<payout> کے لیے ایک اندراج، اور کم از کم سے کم اسٹیک کو مسترد کر دیتا ہے۔ chain 20 کا genesis 1,000 RAND فی قطار کی 26 قطاریں رکھتا ہے، اور کلیدیں وہی ہیں جو chain 19 کی تھیں۔

v0.5.11 سے بلڈ میں genesis ویسٹنگ بھی شامل ہے: وقت سے مقفل الاٹمنٹس کا ایک عوامی رجسٹر، جس میں سے کوئی ناقابلِ تنسیخ اندراج مقفل RAND کو ویلیڈیٹر کے اسٹیک کے طور پر بانڈ کر سکتا ہے (rand-node vesting bond) اور اسے واپس لے سکتا ہے (rand-node vesting unbond)۔ اس کے لیے genesis میں vesting سیکشن درکار ہے۔ کسی چین میں یہ سیکشن نہیں، chain 20 میں بھی نہیں، اور اس کے بغیر یہ کارروائیاں داخلے کے وقت ہی مسترد ہو جاتی ہیں۔ (v0.6.8 یہ بھی ممکن بناتا ہے کہ قابلِ تنسیخ ویسٹنگ اندراج کو صرف دستخط کنندگان کی مقررہ حد ہی ایک طے شدہ خزانے کے حق میں منسوخ کر سکے، اور یہ بھی صرف vesting سیکشن کی موجودگی میں۔)

کیا عوامی ہے

انعامات ان بلاکس کی فیسیں ہیں جو کسی ویلیڈیٹر نے تجویز کیے۔ کوئی بلاک انعام اور کوئی افراطِ زر نہیں، اور chain 20 پر ویلیڈیٹرز کی نہ اسٹیک ضبطی ہوتی ہے نہ معطلی: غلط رویہ اختیار کرنے والے ویلیڈیٹر کا اسٹیک ذرا بھی نہیں کٹتا، اور اس کا تدارک آپریٹرز کے ذمے ہے۔ Fullnode v0.6.8 میں لیڈر کی دوہری دستخط کاری کے لیے اسٹیک ضبطی کا قاعدہ موجود ہے (audit v6, STAKE-1: ایک کلید کی جانب سے ایک ویو کے لیے دو دستخط شدہ بلاک ہیڈر اسٹیک کا equivocation_bps تلف کر دیتے ہیں اور کلید کو معطل کر دیتے ہیں)، لیکن صرف genesis کے staking.slashing سیکشن کے تحت، اور chain 20 میں یہ سیکشن نہیں (rand_getLimits.slashing کی قدر null ہے)؛ fullnode اس کی سفارش صرف اس وقت کرتا ہے جب اسٹیک ایک سے زیادہ آپریٹرز کے پاس ہو۔ (بلاک جمع آوری کے کوڈ میں ایسے جمع کنندگان کے لیے SlashAggregator کارروائی بھی موجود ہے جو ایک ہی نانس پر دو مختلف مجموعوں پر دستخط کریں، اور یہ chain 20 پر فعال نہیں، کیونکہ اس میں جمع آوری کا کوئی سیکشن نہیں۔)

واپس پڑھنا

rand validators        # the whole register
rand status            # is_validator / active_validator for the node asked

→ {"method":"rand_getValidators","params":[]}
← [{ "address": "2nRdFC…", "stake": "1000000000000",
     "pending": [{ "release_epoch": 71, "amount": "1000000000000" }],
     "rewards": "4000000", "payout": "rand1…", "nonce": 3, "active": true, "jailed_until": null }]
→ {"method":"rand_getAdmitted","params":[]}
← { "admission_by_vote": true, "admitted": [], "max": 256 }
→ {"method":"rand_getEpoch","params":[]}
← { "epoch": 69, "epoch_blocks": 1000, "next_set": ["2nRdFC…", "ByDkxs…"] }

رقوم اکائیوں کی اعشاری اسٹرنگز ہیں۔ active بتاتا ہے کہ آیا قطار موجودہ ایپوک چلانے والے سیٹ میں شامل ہے؛ jailed_until کی قدر null ہوتی ہے، سوائے اسٹیک ضبطی کے سیکشن کی موجودگی کے؛ admitted ان کلیدوں کی فہرست ہے جنہیں ووٹ سے داخلہ مل چکا ہے مگر جو ابھی رجسٹر نہیں ہوئیں؛ next_set ایک تخمینہ ہے جسے حد سے پہلے ہر بانڈ اور ان بانڈ بدل دیتا ہے۔ ایکسپلورر کا GET /validators اس میں share_percent، blocks_proposed اور آخری تجویز کردہ بلندی کا اضافہ کرتا ہے۔