diff --git a/searchindex.js b/searchindex.js
index a420520..66b8bcc 100644
--- a/searchindex.js
+++ b/searchindex.js
@@ -1 +1 @@
-Object.assign(window.search, {"doc_urls":["introduction.html#introduction","proposed/0048-session-keys-runtime-api.html#rfc-0048-generate-ownership-proof-for-sessionkeys","proposed/0048-session-keys-runtime-api.html#summary","proposed/0048-session-keys-runtime-api.html#motivation","proposed/0048-session-keys-runtime-api.html#stakeholders","proposed/0048-session-keys-runtime-api.html#explanation","proposed/0048-session-keys-runtime-api.html#drawbacks","proposed/0048-session-keys-runtime-api.html#testing-security-and-privacy","proposed/0048-session-keys-runtime-api.html#performance-ergonomics-and-compatibility","proposed/0048-session-keys-runtime-api.html#performance","proposed/0048-session-keys-runtime-api.html#ergonomics","proposed/0048-session-keys-runtime-api.html#compatibility","proposed/0048-session-keys-runtime-api.html#prior-art-and-references","proposed/0048-session-keys-runtime-api.html#unresolved-questions","proposed/0048-session-keys-runtime-api.html#future-directions-and-related-material","proposed/0074-stateful-multisig-pallet.html#rfc-0074-stateful-multisig-pallet","proposed/0074-stateful-multisig-pallet.html#summary","proposed/0074-stateful-multisig-pallet.html#motivation","proposed/0074-stateful-multisig-pallet.html#problem","proposed/0074-stateful-multisig-pallet.html#requirements","proposed/0074-stateful-multisig-pallet.html#use-cases","proposed/0074-stateful-multisig-pallet.html#stakeholders","proposed/0074-stateful-multisig-pallet.html#explanation","proposed/0074-stateful-multisig-pallet.html#state-transition-functions","proposed/0074-stateful-multisig-pallet.html#storagestate","proposed/0074-stateful-multisig-pallet.html#considerations--edge-cases","proposed/0074-stateful-multisig-pallet.html#drawbacks","proposed/0074-stateful-multisig-pallet.html#testing-security-and-privacy","proposed/0074-stateful-multisig-pallet.html#performance-ergonomics-and-compatibility","proposed/0074-stateful-multisig-pallet.html#performance","proposed/0074-stateful-multisig-pallet.html#ergonomics","proposed/0074-stateful-multisig-pallet.html#compatibility","proposed/0074-stateful-multisig-pallet.html#prior-art-and-references","proposed/0074-stateful-multisig-pallet.html#unresolved-questions","proposed/0074-stateful-multisig-pallet.html#future-directions-and-related-material","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#rfc-0077-increase-maximum-length-of-identity-pgp-fingerprint-values-from-20-bytes","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#summary","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#motivation","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#background","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#problem","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#solution-requirements","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#stakeholders","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#explanation","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#drawbacks","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#testing-security-and-privacy","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#performance-ergonomics-and-compatibility","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#performance","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#ergonomics","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#compatibility","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#prior-art-and-references","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#unresolved-questions","proposed/0077-increase-max-length-of-identity-pgp-fingerprint-value.html#future-directions-and-related-material","approved/0001-agile-coretime.html#rfc-1-agile-coretime","approved/0001-agile-coretime.html#summary","approved/0001-agile-coretime.html#motivation","approved/0001-agile-coretime.html#present-system","approved/0001-agile-coretime.html#problems","approved/0001-agile-coretime.html#requirements","approved/0001-agile-coretime.html#stakeholders","approved/0001-agile-coretime.html#explanation","approved/0001-agile-coretime.html#overview","approved/0001-agile-coretime.html#detail","approved/0001-agile-coretime.html#specific-functions-of-the-coretime-chain","approved/0001-agile-coretime.html#notes-on-the-instantaneous-coretime-market","approved/0001-agile-coretime.html#notes-on-economics","approved/0001-agile-coretime.html#notes-on-types","approved/0001-agile-coretime.html#rollout","approved/0001-agile-coretime.html#performance-ergonomics-and-compatibility","approved/0001-agile-coretime.html#testing-security-and-privacy","approved/0001-agile-coretime.html#future-directions-and-related-material","approved/0001-agile-coretime.html#drawbacks-alternatives-and-unknowns","approved/0001-agile-coretime.html#prior-art-and-references","approved/0005-coretime-interface.html#rfc-5-coretime-interface","approved/0005-coretime-interface.html#summary","approved/0005-coretime-interface.html#motivation","approved/0005-coretime-interface.html#requirements","approved/0005-coretime-interface.html#stakeholders","approved/0005-coretime-interface.html#explanation","approved/0005-coretime-interface.html#ump-message-types","approved/0005-coretime-interface.html#dmp-message-types","approved/0005-coretime-interface.html#realistic-limits-of-the-usage","approved/0005-coretime-interface.html#performance-ergonomics-and-compatibility","approved/0005-coretime-interface.html#testing-security-and-privacy","approved/0005-coretime-interface.html#future-directions-and-related-material","approved/0005-coretime-interface.html#drawbacks-alternatives-and-unknowns","approved/0005-coretime-interface.html#prior-art-and-references","approved/0007-system-collator-selection.html#rfc-0007-system-collator-selection","approved/0007-system-collator-selection.html#summary","approved/0007-system-collator-selection.html#motivation","approved/0007-system-collator-selection.html#requirements","approved/0007-system-collator-selection.html#stakeholders","approved/0007-system-collator-selection.html#explanation","approved/0007-system-collator-selection.html#set-size","approved/0007-system-collator-selection.html#drawbacks","approved/0007-system-collator-selection.html#testing-security-and-privacy","approved/0007-system-collator-selection.html#performance-ergonomics-and-compatibility","approved/0007-system-collator-selection.html#performance","approved/0007-system-collator-selection.html#ergonomics","approved/0007-system-collator-selection.html#compatibility","approved/0007-system-collator-selection.html#prior-art-and-references","approved/0007-system-collator-selection.html#written-discussions","approved/0007-system-collator-selection.html#prior-feedback-and-input-from","approved/0007-system-collator-selection.html#unresolved-questions","approved/0007-system-collator-selection.html#future-directions-and-related-material","approved/0008-parachain-bootnodes-dht.html#rfc-0008-store-parachain-bootnodes-in-relay-chain-dht","approved/0008-parachain-bootnodes-dht.html#summary","approved/0008-parachain-bootnodes-dht.html#motivation","approved/0008-parachain-bootnodes-dht.html#stakeholders","approved/0008-parachain-bootnodes-dht.html#explanation","approved/0008-parachain-bootnodes-dht.html#dht-provider-registration","approved/0008-parachain-bootnodes-dht.html#new-networking-protocol","approved/0008-parachain-bootnodes-dht.html#drawbacks","approved/0008-parachain-bootnodes-dht.html#testing-security-and-privacy","approved/0008-parachain-bootnodes-dht.html#performance-ergonomics-and-compatibility","approved/0008-parachain-bootnodes-dht.html#performance","approved/0008-parachain-bootnodes-dht.html#ergonomics","approved/0008-parachain-bootnodes-dht.html#compatibility","approved/0008-parachain-bootnodes-dht.html#prior-art-and-references","approved/0008-parachain-bootnodes-dht.html#unresolved-questions","approved/0008-parachain-bootnodes-dht.html#future-directions-and-related-material","approved/0010-burn-coretime-revenue.html#rfc-0010-burn-coretime-revenue","approved/0010-burn-coretime-revenue.html#summary","approved/0010-burn-coretime-revenue.html#motivation","approved/0010-burn-coretime-revenue.html#stakeholders","approved/0010-burn-coretime-revenue.html#explanation","approved/0012-process-for-adding-new-collectives.html#rfc-0012-process-for-adding-new-system-collectives","approved/0012-process-for-adding-new-collectives.html#summary","approved/0012-process-for-adding-new-collectives.html#motivation","approved/0012-process-for-adding-new-collectives.html#stakeholders","approved/0012-process-for-adding-new-collectives.html#explanation","approved/0012-process-for-adding-new-collectives.html#removing-collectives","approved/0012-process-for-adding-new-collectives.html#drawbacks","approved/0012-process-for-adding-new-collectives.html#testing-security-and-privacy","approved/0012-process-for-adding-new-collectives.html#performance-ergonomics-and-compatibility","approved/0012-process-for-adding-new-collectives.html#prior-art-and-references","approved/0012-process-for-adding-new-collectives.html#unresolved-questions","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#rfc-0013-prepare-core-runtime-api-for-mbms","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#summary","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#motivation","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#stakeholders","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#explanation","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#coreinitialize_block","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#drawbacks","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#testing-security-and-privacy","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#performance-ergonomics-and-compatibility","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#performance","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#ergonomics","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#compatibility","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#prior-art-and-references","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#unresolved-questions","approved/0013-prepare-blockbuilder-and-core-runtime-apis-for-mbms.html#future-directions-and-related-material","approved/0014-improve-locking-mechanism-for-parachains.html#rfc-0014-improve-locking-mechanism-for-parachains","approved/0014-improve-locking-mechanism-for-parachains.html#summary","approved/0014-improve-locking-mechanism-for-parachains.html#motivation","approved/0014-improve-locking-mechanism-for-parachains.html#requirements","approved/0014-improve-locking-mechanism-for-parachains.html#stakeholders","approved/0014-improve-locking-mechanism-for-parachains.html#explanation","approved/0014-improve-locking-mechanism-for-parachains.html#status-quo","approved/0014-improve-locking-mechanism-for-parachains.html#proposed-changes","approved/0014-improve-locking-mechanism-for-parachains.html#migration","approved/0014-improve-locking-mechanism-for-parachains.html#drawbacks","approved/0014-improve-locking-mechanism-for-parachains.html#testing-security-and-privacy","approved/0014-improve-locking-mechanism-for-parachains.html#performance","approved/0014-improve-locking-mechanism-for-parachains.html#ergonomics","approved/0014-improve-locking-mechanism-for-parachains.html#compatibility","approved/0014-improve-locking-mechanism-for-parachains.html#prior-art-and-references","approved/0014-improve-locking-mechanism-for-parachains.html#unresolved-questions","approved/0014-improve-locking-mechanism-for-parachains.html#future-directions-and-related-material","approved/0022-adopt-encointer-runtime.html#rfc-0022-adopt-encointer-runtime","approved/0022-adopt-encointer-runtime.html#summary","approved/0022-adopt-encointer-runtime.html#motivation","approved/0022-adopt-encointer-runtime.html#stakeholders","approved/0022-adopt-encointer-runtime.html#explanation","approved/0022-adopt-encointer-runtime.html#drawbacks","approved/0022-adopt-encointer-runtime.html#testing-security-and-privacy","approved/0022-adopt-encointer-runtime.html#performance-ergonomics-and-compatibility","approved/0022-adopt-encointer-runtime.html#prior-art-and-references","approved/0022-adopt-encointer-runtime.html#unresolved-questions","approved/0022-adopt-encointer-runtime.html#future-directions-and-related-material","approved/0032-minimal-relay.html#rfc-0032-minimal-relay","approved/0032-minimal-relay.html#summary","approved/0032-minimal-relay.html#motivation","approved/0032-minimal-relay.html#stakeholders","approved/0032-minimal-relay.html#explanation","approved/0032-minimal-relay.html#migrations","approved/0032-minimal-relay.html#interfaces","approved/0032-minimal-relay.html#functional-architecture","approved/0032-minimal-relay.html#resource-allocation","approved/0032-minimal-relay.html#deployment","approved/0032-minimal-relay.html#kusama","approved/0032-minimal-relay.html#drawbacks","approved/0032-minimal-relay.html#testing-security-and-privacy","approved/0032-minimal-relay.html#performance-ergonomics-and-compatibility","approved/0032-minimal-relay.html#performance","approved/0032-minimal-relay.html#ergonomics","approved/0032-minimal-relay.html#compatibility","approved/0032-minimal-relay.html#prior-art-and-references","approved/0032-minimal-relay.html#unresolved-questions","approved/0032-minimal-relay.html#future-directions-and-related-material","approved/0042-extrinsics-state-version.html#rfc-0042-add-system-version-that-replaces-stateversion-on-runtimeversion","approved/0042-extrinsics-state-version.html#summary","approved/0042-extrinsics-state-version.html#motivation","approved/0042-extrinsics-state-version.html#stakeholders","approved/0042-extrinsics-state-version.html#explanation","approved/0042-extrinsics-state-version.html#drawbacks","approved/0042-extrinsics-state-version.html#testing-security-and-privacy","approved/0042-extrinsics-state-version.html#performance-ergonomics-and-compatibility","approved/0042-extrinsics-state-version.html#performance","approved/0042-extrinsics-state-version.html#ergonomics","approved/0042-extrinsics-state-version.html#compatibility","approved/0042-extrinsics-state-version.html#prior-art-and-references","approved/0042-extrinsics-state-version.html#unresolved-questions","approved/0042-extrinsics-state-version.html#future-directions-and-related-material","approved/0043-storage-proof-size-hostfunction.html#rfc-0043-introduce-storage_proof_size-host-function-for-improved-parachain-block-utilization","approved/0043-storage-proof-size-hostfunction.html#summary","approved/0043-storage-proof-size-hostfunction.html#motivation","approved/0043-storage-proof-size-hostfunction.html#stakeholders","approved/0043-storage-proof-size-hostfunction.html#explanation","approved/0043-storage-proof-size-hostfunction.html#performance-ergonomics-and-compatibility","approved/0043-storage-proof-size-hostfunction.html#performance","approved/0043-storage-proof-size-hostfunction.html#ergonomics","approved/0043-storage-proof-size-hostfunction.html#compatibility","approved/0043-storage-proof-size-hostfunction.html#prior-art-and-references","approved/0045-nft-deposits-asset-hub.html#rfc-0045-lowering-nft-deposits-on-asset-hub","approved/0045-nft-deposits-asset-hub.html#summary","approved/0045-nft-deposits-asset-hub.html#motivation","approved/0045-nft-deposits-asset-hub.html#requirements","approved/0045-nft-deposits-asset-hub.html#stakeholders","approved/0045-nft-deposits-asset-hub.html#explanation","approved/0045-nft-deposits-asset-hub.html#enhanced-approach-to-further-lower-barriers-for-entry","approved/0045-nft-deposits-asset-hub.html#short--and-long-term-plans","approved/0045-nft-deposits-asset-hub.html#drawbacks","approved/0045-nft-deposits-asset-hub.html#testing-security-and-privacy","approved/0045-nft-deposits-asset-hub.html#security-concerns","approved/0045-nft-deposits-asset-hub.html#performance-ergonomics-and-compatibility","approved/0045-nft-deposits-asset-hub.html#performance","approved/0045-nft-deposits-asset-hub.html#ergonomics","approved/0045-nft-deposits-asset-hub.html#compatibility","approved/0045-nft-deposits-asset-hub.html#unresolved-questions","approved/0045-nft-deposits-asset-hub.html#addendum","approved/0045-nft-deposits-asset-hub.html#enhanced-weak-governance-origin-model","approved/0045-nft-deposits-asset-hub.html#function-based-pricing-model","approved/0045-nft-deposits-asset-hub.html#linking-deposit-to-usdx-value","approved/0047-assignment-of-availability-chunks.html#rfc-0047-assignment-of-availability-chunks-to-validators","approved/0047-assignment-of-availability-chunks.html#summary","approved/0047-assignment-of-availability-chunks.html#motivation","approved/0047-assignment-of-availability-chunks.html#stakeholders","approved/0047-assignment-of-availability-chunks.html#explanation","approved/0047-assignment-of-availability-chunks.html#systematic-erasure-codes","approved/0047-assignment-of-availability-chunks.html#availability-recovery-at-present","approved/0047-assignment-of-availability-chunks.html#availability-recovery-from-systematic-chunks","approved/0047-assignment-of-availability-chunks.html#chunk-assignment-function","approved/0047-assignment-of-availability-chunks.html#network-protocol","approved/0047-assignment-of-availability-chunks.html#upgrade-path","approved/0047-assignment-of-availability-chunks.html#drawbacks","approved/0047-assignment-of-availability-chunks.html#testing-security-and-privacy","approved/0047-assignment-of-availability-chunks.html#performance-ergonomics-and-compatibility","approved/0047-assignment-of-availability-chunks.html#performance","approved/0047-assignment-of-availability-chunks.html#ergonomics","approved/0047-assignment-of-availability-chunks.html#compatibility","approved/0047-assignment-of-availability-chunks.html#prior-art-and-references","approved/0047-assignment-of-availability-chunks.html#unresolved-questions","approved/0047-assignment-of-availability-chunks.html#future-directions-and-related-material","approved/0047-assignment-of-availability-chunks.html#appendix-a","approved/0050-fellowship-salaries.html#rfc-0050-fellowship-salaries","approved/0050-fellowship-salaries.html#summary","approved/0050-fellowship-salaries.html#motivation","approved/0050-fellowship-salaries.html#stakeholders","approved/0050-fellowship-salaries.html#explanation","approved/0050-fellowship-salaries.html#salary-asset","approved/0050-fellowship-salaries.html#projections","approved/0050-fellowship-salaries.html#updates","approved/0050-fellowship-salaries.html#drawbacks","approved/0050-fellowship-salaries.html#testing-security-and-privacy","approved/0050-fellowship-salaries.html#performance-ergonomics-and-compatibility","approved/0050-fellowship-salaries.html#performance","approved/0050-fellowship-salaries.html#ergonomics","approved/0050-fellowship-salaries.html#compatibility","approved/0050-fellowship-salaries.html#prior-art-and-references","approved/0050-fellowship-salaries.html#unresolved-questions","approved/0056-one-transaction-per-notification.html#rfc-0056-enforce-only-one-transaction-per-notification","approved/0056-one-transaction-per-notification.html#summary","approved/0056-one-transaction-per-notification.html#motivation","approved/0056-one-transaction-per-notification.html#stakeholders","approved/0056-one-transaction-per-notification.html#explanation","approved/0056-one-transaction-per-notification.html#drawbacks","approved/0056-one-transaction-per-notification.html#testing-security-and-privacy","approved/0056-one-transaction-per-notification.html#performance-ergonomics-and-compatibility","approved/0056-one-transaction-per-notification.html#performance","approved/0056-one-transaction-per-notification.html#ergonomics","approved/0056-one-transaction-per-notification.html#compatibility","approved/0056-one-transaction-per-notification.html#prior-art-and-references","approved/0056-one-transaction-per-notification.html#unresolved-questions","approved/0056-one-transaction-per-notification.html#future-directions-and-related-material","approved/0059-nodes-capabilities-discovery.html#rfc-0059-add-a-discovery-mechanism-for-nodes-based-on-their-capabilities","approved/0059-nodes-capabilities-discovery.html#summary","approved/0059-nodes-capabilities-discovery.html#motivation","approved/0059-nodes-capabilities-discovery.html#stakeholders","approved/0059-nodes-capabilities-discovery.html#explanation","approved/0059-nodes-capabilities-discovery.html#capabilities","approved/0059-nodes-capabilities-discovery.html#dht-provider-registration","approved/0059-nodes-capabilities-discovery.html#secondary-dhts","approved/0059-nodes-capabilities-discovery.html#head-of-the-chain-providers","approved/0059-nodes-capabilities-discovery.html#drawbacks","approved/0059-nodes-capabilities-discovery.html#testing-security-and-privacy","approved/0059-nodes-capabilities-discovery.html#performance-ergonomics-and-compatibility","approved/0059-nodes-capabilities-discovery.html#performance","approved/0059-nodes-capabilities-discovery.html#ergonomics","approved/0059-nodes-capabilities-discovery.html#compatibility","approved/0059-nodes-capabilities-discovery.html#prior-art-and-references","approved/0059-nodes-capabilities-discovery.html#unresolved-questions","approved/0059-nodes-capabilities-discovery.html#future-directions-and-related-material","approved/0078-merkleized-metadata.html#rfc-0078-merkleized-metadata","approved/0078-merkleized-metadata.html#summary","approved/0078-merkleized-metadata.html#motivation","approved/0078-merkleized-metadata.html#requirements","approved/0078-merkleized-metadata.html#reduce-metadata-size","approved/0078-merkleized-metadata.html#stakeholders","approved/0078-merkleized-metadata.html#explanation","approved/0078-merkleized-metadata.html#metadata-digest","approved/0078-merkleized-metadata.html#extrinsic-metadata","approved/0078-merkleized-metadata.html#type-information","approved/0078-merkleized-metadata.html#prune-unrelated-types","approved/0078-merkleized-metadata.html#generating-typeref","approved/0078-merkleized-metadata.html#building-the-merkle-tree-root","approved/0078-merkleized-metadata.html#inclusion-in-an-extrinsic","approved/0078-merkleized-metadata.html#drawbacks","approved/0078-merkleized-metadata.html#testing-security-and-privacy","approved/0078-merkleized-metadata.html#performance-ergonomics-and-compatibility","approved/0078-merkleized-metadata.html#performance","approved/0078-merkleized-metadata.html#ergonomics--compatibility","approved/0078-merkleized-metadata.html#prior-art-and-references","approved/0078-merkleized-metadata.html#unresolved-questions","approved/0078-merkleized-metadata.html#future-directions-and-related-material","approved/0084-general-transaction-extrinsic-format.html#rfc-0084-general-transactions-in-extrinsic-format","approved/0084-general-transaction-extrinsic-format.html#summary","approved/0084-general-transaction-extrinsic-format.html#motivation","approved/0084-general-transaction-extrinsic-format.html#stakeholders","approved/0084-general-transaction-extrinsic-format.html#explanation","approved/0084-general-transaction-extrinsic-format.html#drawbacks","approved/0084-general-transaction-extrinsic-format.html#testing-security-and-privacy","approved/0084-general-transaction-extrinsic-format.html#performance-ergonomics-and-compatibility","approved/0084-general-transaction-extrinsic-format.html#performance","approved/0084-general-transaction-extrinsic-format.html#ergonomics","approved/0084-general-transaction-extrinsic-format.html#compatibility","approved/0084-general-transaction-extrinsic-format.html#prior-art-and-references","approved/0084-general-transaction-extrinsic-format.html#unresolved-questions","approved/0084-general-transaction-extrinsic-format.html#future-directions-and-related-material","stale/0004-remove-unnecessary-allocator-usage.html#rfc-0004-remove-the-host-side-runtime-memory-allocator","stale/0004-remove-unnecessary-allocator-usage.html#summary","stale/0004-remove-unnecessary-allocator-usage.html#motivation","stale/0004-remove-unnecessary-allocator-usage.html#stakeholders","stale/0004-remove-unnecessary-allocator-usage.html#explanation","stale/0004-remove-unnecessary-allocator-usage.html#new-host-functions","stale/0004-remove-unnecessary-allocator-usage.html#other-changes","stale/0004-remove-unnecessary-allocator-usage.html#drawbacks","stale/0004-remove-unnecessary-allocator-usage.html#prior-art","stale/0004-remove-unnecessary-allocator-usage.html#unresolved-questions","stale/0004-remove-unnecessary-allocator-usage.html#future-possibilities","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#rfc-0006-dynamic-pricing-for-bulk-coretime-sales","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#summary","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#motivation","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#requirements","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#stakeholders","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#explanation","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#overview","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#parameters","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#function","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#pseudo-code","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#properties-of-the-curve","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#example-configurations","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#drawbacks","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#prior-art-and-references","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#future-possibilities","stale/0006-dynamic-pricing-for-bulk-coretime-sales.html#references","stale/0009-improved-net-light-client-requests.html#rfc-0009-improved-light-client-requests-networking-protocol","stale/0009-improved-net-light-client-requests.html#summary","stale/0009-improved-net-light-client-requests.html#motivation","stale/0009-improved-net-light-client-requests.html#stakeholders","stale/0009-improved-net-light-client-requests.html#explanation","stale/0009-improved-net-light-client-requests.html#drawbacks","stale/0009-improved-net-light-client-requests.html#testing-security-and-privacy","stale/0009-improved-net-light-client-requests.html#performance-ergonomics-and-compatibility","stale/0009-improved-net-light-client-requests.html#performance","stale/0009-improved-net-light-client-requests.html#ergonomics","stale/0009-improved-net-light-client-requests.html#compatibility","stale/0009-improved-net-light-client-requests.html#prior-art-and-references","stale/0009-improved-net-light-client-requests.html#unresolved-questions","stale/0009-improved-net-light-client-requests.html#future-directions-and-related-material","stale/0015-market-design-revisit.html#rfc-0015-market-design-revisit","stale/0015-market-design-revisit.html#summary","stale/0015-market-design-revisit.html#motivation","stale/0015-market-design-revisit.html#stakeholders","stale/0015-market-design-revisit.html#explanation","stale/0015-market-design-revisit.html#bulk-markets","stale/0015-market-design-revisit.html#benefits-of-this-system","stale/0015-market-design-revisit.html#further-discussion-points","stale/0015-market-design-revisit.html#drawbacks","stale/0015-market-design-revisit.html#prior-art-and-references","stale/0015-market-design-revisit.html#unresolved-questions","stale/0020-treasurer-track-confirmation-period-duration-modification.html#rfc-0020-treasurer-track-confirmation-period-duration-modification","stale/0020-treasurer-track-confirmation-period-duration-modification.html#summary","stale/0020-treasurer-track-confirmation-period-duration-modification.html#motivation","stale/0020-treasurer-track-confirmation-period-duration-modification.html#stakeholders","stale/0020-treasurer-track-confirmation-period-duration-modification.html#explanation","stale/0020-treasurer-track-confirmation-period-duration-modification.html#drawbacks","stale/0020-treasurer-track-confirmation-period-duration-modification.html#testing-security-and-privacy","stale/0020-treasurer-track-confirmation-period-duration-modification.html#performance-ergonomics-and-compatibility","stale/0020-treasurer-track-confirmation-period-duration-modification.html#performance","stale/0020-treasurer-track-confirmation-period-duration-modification.html#ergonomics--compatibility","stale/0020-treasurer-track-confirmation-period-duration-modification.html#prior-art-and-references","stale/0020-treasurer-track-confirmation-period-duration-modification.html#unresolved-questions","stale/0020-treasurer-track-confirmation-period-duration-modification.html#future-directions-and-related-material","stale/0026-sassafras-consensus.html#rfc-0026-sassafras-consensus-protocol","stale/0026-sassafras-consensus.html#abstract","stale/0026-sassafras-consensus.html#1-motivation","stale/0026-sassafras-consensus.html#11-relevance-to-implementors","stale/0026-sassafras-consensus.html#12-supporting-sassafras-for-polkadot","stale/0026-sassafras-consensus.html#2-stakeholders","stale/0026-sassafras-consensus.html#21-blockchain-developers","stale/0026-sassafras-consensus.html#22-polkadot-ecosystem-contributors","stale/0026-sassafras-consensus.html#3-notation-and-convention","stale/0026-sassafras-consensus.html#31-data-structures-definitions-and-encoding","stale/0026-sassafras-consensus.html#32-pseudo-code","stale/0026-sassafras-consensus.html#33-incremental-introduction-of-types-and-functions","stale/0026-sassafras-consensus.html#4-protocol-introduction","stale/0026-sassafras-consensus.html#41-submission-of-candidate-tickets","stale/0026-sassafras-consensus.html#42-validation-of-candidate-tickets","stale/0026-sassafras-consensus.html#43-tickets-and-slots-binding","stale/0026-sassafras-consensus.html#44-claim-of-ticket-ownership","stale/0026-sassafras-consensus.html#45-validation-of-ticket-ownership","stale/0026-sassafras-consensus.html#5-bandersnatch-vrfs-cryptographic-primitives","stale/0026-sassafras-consensus.html#51-vrf-input","stale/0026-sassafras-consensus.html#52-vrf-preoutput","stale/0026-sassafras-consensus.html#53-vrf-signature-data","stale/0026-sassafras-consensus.html#54-vrf-signature","stale/0026-sassafras-consensus.html#6-sassafras-protocol","stale/0026-sassafras-consensus.html#61-epochs-first-block","stale/0026-sassafras-consensus.html#62-creation-and-submission-of-candidate-tickets","stale/0026-sassafras-consensus.html#63-validation-of-candidate-tickets","stale/0026-sassafras-consensus.html#64-ticket-slot-binding","stale/0026-sassafras-consensus.html#65-slot-claim-production","stale/0026-sassafras-consensus.html#66-slot-claim-verification","stale/0026-sassafras-consensus.html#661-primary-method","stale/0026-sassafras-consensus.html#67-randomness-accumulator","stale/0026-sassafras-consensus.html#7-drawbacks","stale/0026-sassafras-consensus.html#8-testing-security-and-privacy","stale/0026-sassafras-consensus.html#9-performance-ergonomics-and-compatibility","stale/0026-sassafras-consensus.html#91-performance","stale/0026-sassafras-consensus.html#92-ergonomics","stale/0026-sassafras-consensus.html#93-compatibility","stale/0026-sassafras-consensus.html#10-prior-art-and-references","stale/0026-sassafras-consensus.html#11-unresolved-questions","stale/0026-sassafras-consensus.html#12-future-directions-and-related-material","stale/0026-sassafras-consensus.html#121-interactions-with-on-chain-code","stale/0026-sassafras-consensus.html#122-deployment-strategies","stale/0026-sassafras-consensus.html#123-zk-snark-srs-initialization","stale/0026-sassafras-consensus.html#124-anonymous-submission-of-tickets","stale/0034-xcm-absolute-location-account-derivation.html#rfc-34-xcm-absolute-location-account-derivation","stale/0034-xcm-absolute-location-account-derivation.html#summary","stale/0034-xcm-absolute-location-account-derivation.html#motivation","stale/0034-xcm-absolute-location-account-derivation.html#stakeholders","stale/0034-xcm-absolute-location-account-derivation.html#explanation","stale/0034-xcm-absolute-location-account-derivation.html#drawbacks","stale/0034-xcm-absolute-location-account-derivation.html#testing-security-and-privacy","stale/0034-xcm-absolute-location-account-derivation.html#performance-ergonomics-and-compatibility","stale/0034-xcm-absolute-location-account-derivation.html#performance","stale/0034-xcm-absolute-location-account-derivation.html#ergonomics","stale/0034-xcm-absolute-location-account-derivation.html#compatibility","stale/0034-xcm-absolute-location-account-derivation.html#prior-art-and-references","stale/0034-xcm-absolute-location-account-derivation.html#unresolved-questions","stale/0035-conviction-voting-delegation-modifications.html#rfc-0035-conviction-voting-delegation-modifications","stale/0035-conviction-voting-delegation-modifications.html#summary","stale/0035-conviction-voting-delegation-modifications.html#motivation","stale/0035-conviction-voting-delegation-modifications.html#stakeholders","stale/0035-conviction-voting-delegation-modifications.html#explanation","stale/0035-conviction-voting-delegation-modifications.html#drawbacks","stale/0035-conviction-voting-delegation-modifications.html#testing-security-and-privacy","stale/0035-conviction-voting-delegation-modifications.html#performance-ergonomics-and-compatibility","stale/0035-conviction-voting-delegation-modifications.html#performance","stale/0035-conviction-voting-delegation-modifications.html#ergonomics--compatibility","stale/0035-conviction-voting-delegation-modifications.html#prior-art-and-references","stale/0035-conviction-voting-delegation-modifications.html#unresolved-questions","stale/0035-conviction-voting-delegation-modifications.html#future-directions-and-related-material","stale/0044-rent-based-registration.html#rfc-0044-rent-based-registration-model","stale/0044-rent-based-registration.html#summary","stale/0044-rent-based-registration.html#motivation","stale/0044-rent-based-registration.html#requirements","stale/0044-rent-based-registration.html#stakeholders","stale/0044-rent-based-registration.html#explanation","stale/0044-rent-based-registration.html#registering-an-on-demand-parachain","stale/0044-rent-based-registration.html#on-demand-parachain-pruning","stale/0044-rent-based-registration.html#ensuring-rent-is-paid","stale/0044-rent-based-registration.html#on-demand-para-re-registration","stale/0044-rent-based-registration.html#drawbacks","stale/0044-rent-based-registration.html#testing-security-and-privacy","stale/0044-rent-based-registration.html#performance-ergonomics-and-compatibility","stale/0044-rent-based-registration.html#performance","stale/0044-rent-based-registration.html#ergonomics","stale/0044-rent-based-registration.html#compatibility","stale/0044-rent-based-registration.html#prior-art-and-references","stale/0044-rent-based-registration.html#unresolved-questions","stale/0044-rent-based-registration.html#future-directions-and-related-material","stale/0054-remove-heap-pages.html#rfc-0054-remove-the-concept-of-heap-pages-from-the-client","stale/0054-remove-heap-pages.html#summary","stale/0054-remove-heap-pages.html#motivation","stale/0054-remove-heap-pages.html#stakeholders","stale/0054-remove-heap-pages.html#explanation","stale/0054-remove-heap-pages.html#drawbacks","stale/0054-remove-heap-pages.html#testing-security-and-privacy","stale/0054-remove-heap-pages.html#performance-ergonomics-and-compatibility","stale/0054-remove-heap-pages.html#performance","stale/0054-remove-heap-pages.html#ergonomics","stale/0054-remove-heap-pages.html#compatibility","stale/0054-remove-heap-pages.html#prior-art-and-references","stale/0054-remove-heap-pages.html#unresolved-questions","stale/0054-remove-heap-pages.html#future-directions-and-related-material","stale/0070-x-track-kusamanetwork.html#rfc-0070-x-track-for--kusamanetwork","stale/0070-x-track-kusamanetwork.html#summary","stale/0070-x-track-kusamanetwork.html#motivation","stale/0070-x-track-kusamanetwork.html#stakeholders","stale/0070-x-track-kusamanetwork.html#explanation","stale/0070-x-track-kusamanetwork.html#phase-1---track-configurations","stale/0070-x-track-kusamanetwork.html#phase-2---establish-specs-for-x-post-track-referenda","stale/0070-x-track-kusamanetwork.html#phase-3---release-tooling--documentation","stale/0070-x-track-kusamanetwork.html#drawbacks","stale/0070-x-track-kusamanetwork.html#testing-security-and-privacy","stale/0070-x-track-kusamanetwork.html#performance-ergonomics-and-compatibility","stale/0070-x-track-kusamanetwork.html#performance","stale/0070-x-track-kusamanetwork.html#ergonomics","stale/0070-x-track-kusamanetwork.html#compatibility","stale/0070-x-track-kusamanetwork.html#references","stale/0070-x-track-kusamanetwork.html#unresolved-questions","stale/0073-referedum-deposit-track.html#rfc-0073-decision-deposit-referendum-track","stale/0073-referedum-deposit-track.html#summary","stale/0073-referedum-deposit-track.html#motivation","stale/0073-referedum-deposit-track.html#explanation","stale/0073-referedum-deposit-track.html#referendum-track-parameters---polkadot","stale/0073-referedum-deposit-track.html#referendum-track-parameters---kusama","stale/0073-referedum-deposit-track.html#drawbacks","stale/0073-referedum-deposit-track.html#testing-security-and-privacy","stale/0073-referedum-deposit-track.html#performance-ergonomics-and-compatibility","stale/0073-referedum-deposit-track.html#performance","stale/0073-referedum-deposit-track.html#ergonomics","stale/0073-referedum-deposit-track.html#compatibility","stale/0073-referedum-deposit-track.html#prior-art-and-references","stale/0073-referedum-deposit-track.html#unresolved-questions"],"index":{"documentStore":{"docInfo":{"0":{"body":16,"breadcrumbs":2,"title":1},"1":{"body":51,"breadcrumbs":12,"title":6},"10":{"body":8,"breadcrumbs":7,"title":1},"100":{"body":16,"breadcrumbs":7,"title":2},"101":{"body":21,"breadcrumbs":8,"title":3},"102":{"body":2,"breadcrumbs":7,"title":2},"103":{"body":13,"breadcrumbs":9,"title":4},"104":{"body":57,"breadcrumbs":16,"title":8},"105":{"body":29,"breadcrumbs":9,"title":1},"106":{"body":185,"breadcrumbs":9,"title":1},"107":{"body":15,"breadcrumbs":9,"title":1},"108":{"body":60,"breadcrumbs":9,"title":1},"109":{"body":110,"breadcrumbs":11,"title":3},"11":{"body":46,"breadcrumbs":7,"title":1},"110":{"body":153,"breadcrumbs":11,"title":3},"111":{"body":96,"breadcrumbs":9,"title":1},"112":{"body":144,"breadcrumbs":11,"title":3},"113":{"body":0,"breadcrumbs":11,"title":3},"114":{"body":110,"breadcrumbs":9,"title":1},"115":{"body":1,"breadcrumbs":9,"title":1},"116":{"body":1,"breadcrumbs":9,"title":1},"117":{"body":1,"breadcrumbs":11,"title":3},"118":{"body":21,"breadcrumbs":10,"title":2},"119":{"body":11,"breadcrumbs":12,"title":4},"12":{"body":1,"breadcrumbs":9,"title":3},"120":{"body":23,"breadcrumbs":10,"title":5},"121":{"body":36,"breadcrumbs":6,"title":1},"122":{"body":21,"breadcrumbs":6,"title":1},"123":{"body":4,"breadcrumbs":6,"title":1},"124":{"body":290,"breadcrumbs":6,"title":1},"125":{"body":44,"breadcrumbs":14,"title":7},"126":{"body":43,"breadcrumbs":8,"title":1},"127":{"body":81,"breadcrumbs":8,"title":1},"128":{"body":10,"breadcrumbs":8,"title":1},"129":{"body":101,"breadcrumbs":8,"title":1},"13":{"body":1,"breadcrumbs":8,"title":2},"130":{"body":70,"breadcrumbs":9,"title":2},"131":{"body":16,"breadcrumbs":8,"title":1},"132":{"body":1,"breadcrumbs":10,"title":3},"133":{"body":39,"breadcrumbs":10,"title":3},"134":{"body":7,"breadcrumbs":10,"title":3},"135":{"body":2,"breadcrumbs":9,"title":2},"136":{"body":51,"breadcrumbs":14,"title":7},"137":{"body":15,"breadcrumbs":8,"title":1},"138":{"body":50,"breadcrumbs":8,"title":1},"139":{"body":27,"breadcrumbs":8,"title":1},"14":{"body":3,"breadcrumbs":10,"title":4},"140":{"body":0,"breadcrumbs":8,"title":1},"141":{"body":117,"breadcrumbs":8,"title":1},"142":{"body":14,"breadcrumbs":8,"title":1},"143":{"body":15,"breadcrumbs":10,"title":3},"144":{"body":0,"breadcrumbs":10,"title":3},"145":{"body":19,"breadcrumbs":8,"title":1},"146":{"body":17,"breadcrumbs":8,"title":1},"147":{"body":16,"breadcrumbs":8,"title":1},"148":{"body":26,"breadcrumbs":10,"title":3},"149":{"body":30,"breadcrumbs":9,"title":2},"15":{"body":58,"breadcrumbs":10,"title":5},"150":{"body":35,"breadcrumbs":11,"title":4},"151":{"body":48,"breadcrumbs":12,"title":6},"152":{"body":35,"breadcrumbs":7,"title":1},"153":{"body":152,"breadcrumbs":7,"title":1},"154":{"body":32,"breadcrumbs":7,"title":1},"155":{"body":4,"breadcrumbs":7,"title":1},"156":{"body":0,"breadcrumbs":7,"title":1},"157":{"body":92,"breadcrumbs":8,"title":2},"158":{"body":52,"breadcrumbs":8,"title":2},"159":{"body":32,"breadcrumbs":7,"title":1},"16":{"body":77,"breadcrumbs":6,"title":1},"160":{"body":111,"breadcrumbs":7,"title":1},"161":{"body":19,"breadcrumbs":9,"title":3},"162":{"body":4,"breadcrumbs":7,"title":1},"163":{"body":8,"breadcrumbs":7,"title":1},"164":{"body":5,"breadcrumbs":7,"title":1},"165":{"body":26,"breadcrumbs":9,"title":3},"166":{"body":2,"breadcrumbs":8,"title":2},"167":{"body":34,"breadcrumbs":10,"title":4},"168":{"body":48,"breadcrumbs":10,"title":5},"169":{"body":20,"breadcrumbs":6,"title":1},"17":{"body":0,"breadcrumbs":6,"title":1},"170":{"body":30,"breadcrumbs":6,"title":1},"171":{"body":52,"breadcrumbs":6,"title":1},"172":{"body":73,"breadcrumbs":6,"title":1},"173":{"body":38,"breadcrumbs":6,"title":1},"174":{"body":7,"breadcrumbs":8,"title":3},"175":{"body":1,"breadcrumbs":8,"title":3},"176":{"body":4,"breadcrumbs":8,"title":3},"177":{"body":2,"breadcrumbs":7,"title":2},"178":{"body":4,"breadcrumbs":9,"title":4},"179":{"body":54,"breadcrumbs":8,"title":4},"18":{"body":185,"breadcrumbs":6,"title":1},"180":{"body":22,"breadcrumbs":5,"title":1},"181":{"body":85,"breadcrumbs":5,"title":1},"182":{"body":16,"breadcrumbs":5,"title":1},"183":{"body":42,"breadcrumbs":5,"title":1},"184":{"body":62,"breadcrumbs":5,"title":1},"185":{"body":62,"breadcrumbs":5,"title":1},"186":{"body":127,"breadcrumbs":6,"title":2},"187":{"body":101,"breadcrumbs":6,"title":2},"188":{"body":324,"breadcrumbs":5,"title":1},"189":{"body":117,"breadcrumbs":5,"title":1},"19":{"body":60,"breadcrumbs":6,"title":1},"190":{"body":12,"breadcrumbs":5,"title":1},"191":{"body":13,"breadcrumbs":7,"title":3},"192":{"body":6,"breadcrumbs":7,"title":3},"193":{"body":12,"breadcrumbs":5,"title":1},"194":{"body":35,"breadcrumbs":5,"title":1},"195":{"body":17,"breadcrumbs":5,"title":1},"196":{"body":7,"breadcrumbs":7,"title":3},"197":{"body":14,"breadcrumbs":6,"title":2},"198":{"body":23,"breadcrumbs":8,"title":4},"199":{"body":49,"breadcrumbs":16,"title":8},"2":{"body":82,"breadcrumbs":7,"title":1},"20":{"body":63,"breadcrumbs":7,"title":2},"200":{"body":33,"breadcrumbs":9,"title":1},"201":{"body":94,"breadcrumbs":9,"title":1},"202":{"body":6,"breadcrumbs":9,"title":1},"203":{"body":97,"breadcrumbs":9,"title":1},"204":{"body":11,"breadcrumbs":9,"title":1},"205":{"body":4,"breadcrumbs":11,"title":3},"206":{"body":8,"breadcrumbs":11,"title":3},"207":{"body":4,"breadcrumbs":9,"title":1},"208":{"body":3,"breadcrumbs":9,"title":1},"209":{"body":3,"breadcrumbs":9,"title":1},"21":{"body":4,"breadcrumbs":6,"title":1},"210":{"body":12,"breadcrumbs":11,"title":3},"211":{"body":4,"breadcrumbs":10,"title":2},"212":{"body":9,"breadcrumbs":12,"title":4},"213":{"body":42,"breadcrumbs":20,"title":10},"214":{"body":28,"breadcrumbs":11,"title":1},"215":{"body":121,"breadcrumbs":11,"title":1},"216":{"body":15,"breadcrumbs":11,"title":1},"217":{"body":70,"breadcrumbs":11,"title":1},"218":{"body":0,"breadcrumbs":13,"title":3},"219":{"body":26,"breadcrumbs":11,"title":1},"22":{"body":121,"breadcrumbs":6,"title":1},"220":{"body":26,"breadcrumbs":11,"title":1},"221":{"body":7,"breadcrumbs":11,"title":1},"222":{"body":19,"breadcrumbs":13,"title":3},"223":{"body":78,"breadcrumbs":14,"title":7},"224":{"body":37,"breadcrumbs":8,"title":1},"225":{"body":101,"breadcrumbs":8,"title":1},"226":{"body":8,"breadcrumbs":8,"title":1},"227":{"body":67,"breadcrumbs":8,"title":1},"228":{"body":98,"breadcrumbs":8,"title":1},"229":{"body":111,"breadcrumbs":13,"title":6},"23":{"body":865,"breadcrumbs":8,"title":3},"230":{"body":112,"breadcrumbs":11,"title":4},"231":{"body":154,"breadcrumbs":8,"title":1},"232":{"body":0,"breadcrumbs":10,"title":3},"233":{"body":19,"breadcrumbs":9,"title":2},"234":{"body":0,"breadcrumbs":10,"title":3},"235":{"body":35,"breadcrumbs":8,"title":1},"236":{"body":20,"breadcrumbs":8,"title":1},"237":{"body":7,"breadcrumbs":8,"title":1},"238":{"body":10,"breadcrumbs":9,"title":2},"239":{"body":26,"breadcrumbs":8,"title":1},"24":{"body":224,"breadcrumbs":6,"title":1},"240":{"body":77,"breadcrumbs":12,"title":5},"241":{"body":60,"breadcrumbs":11,"title":4},"242":{"body":87,"breadcrumbs":11,"title":4},"243":{"body":67,"breadcrumbs":12,"title":6},"244":{"body":20,"breadcrumbs":7,"title":1},"245":{"body":66,"breadcrumbs":7,"title":1},"246":{"body":5,"breadcrumbs":7,"title":1},"247":{"body":0,"breadcrumbs":7,"title":1},"248":{"body":77,"breadcrumbs":9,"title":3},"249":{"body":94,"breadcrumbs":9,"title":3},"25":{"body":139,"breadcrumbs":8,"title":3},"250":{"body":82,"breadcrumbs":10,"title":4},"251":{"body":99,"breadcrumbs":9,"title":3},"252":{"body":261,"breadcrumbs":8,"title":2},"253":{"body":172,"breadcrumbs":8,"title":2},"254":{"body":59,"breadcrumbs":7,"title":1},"255":{"body":11,"breadcrumbs":9,"title":3},"256":{"body":0,"breadcrumbs":9,"title":3},"257":{"body":45,"breadcrumbs":7,"title":1},"258":{"body":1,"breadcrumbs":7,"title":1},"259":{"body":19,"breadcrumbs":7,"title":1},"26":{"body":3,"breadcrumbs":6,"title":1},"260":{"body":6,"breadcrumbs":9,"title":3},"261":{"body":1,"breadcrumbs":8,"title":2},"262":{"body":13,"breadcrumbs":10,"title":4},"263":{"body":217,"breadcrumbs":7,"title":1},"264":{"body":48,"breadcrumbs":8,"title":4},"265":{"body":16,"breadcrumbs":5,"title":1},"266":{"body":70,"breadcrumbs":5,"title":1},"267":{"body":4,"breadcrumbs":5,"title":1},"268":{"body":78,"breadcrumbs":5,"title":1},"269":{"body":92,"breadcrumbs":6,"title":2},"27":{"body":4,"breadcrumbs":8,"title":3},"270":{"body":67,"breadcrumbs":5,"title":1},"271":{"body":12,"breadcrumbs":5,"title":1},"272":{"body":13,"breadcrumbs":5,"title":1},"273":{"body":1,"breadcrumbs":7,"title":3},"274":{"body":0,"breadcrumbs":7,"title":3},"275":{"body":1,"breadcrumbs":5,"title":1},"276":{"body":1,"breadcrumbs":5,"title":1},"277":{"body":1,"breadcrumbs":5,"title":1},"278":{"body":12,"breadcrumbs":7,"title":3},"279":{"body":2,"breadcrumbs":6,"title":2},"28":{"body":0,"breadcrumbs":8,"title":3},"280":{"body":51,"breadcrumbs":14,"title":7},"281":{"body":44,"breadcrumbs":8,"title":1},"282":{"body":100,"breadcrumbs":8,"title":1},"283":{"body":3,"breadcrumbs":8,"title":1},"284":{"body":121,"breadcrumbs":8,"title":1},"285":{"body":33,"breadcrumbs":8,"title":1},"286":{"body":1,"breadcrumbs":10,"title":3},"287":{"body":0,"breadcrumbs":10,"title":3},"288":{"body":1,"breadcrumbs":8,"title":1},"289":{"body":1,"breadcrumbs":8,"title":1},"29":{"body":243,"breadcrumbs":6,"title":1},"290":{"body":19,"breadcrumbs":8,"title":1},"291":{"body":1,"breadcrumbs":10,"title":3},"292":{"body":1,"breadcrumbs":9,"title":2},"293":{"body":4,"breadcrumbs":11,"title":4},"294":{"body":60,"breadcrumbs":16,"title":8},"295":{"body":32,"breadcrumbs":9,"title":1},"296":{"body":98,"breadcrumbs":9,"title":1},"297":{"body":9,"breadcrumbs":9,"title":1},"298":{"body":23,"breadcrumbs":9,"title":1},"299":{"body":232,"breadcrumbs":9,"title":1},"3":{"body":73,"breadcrumbs":7,"title":1},"30":{"body":11,"breadcrumbs":6,"title":1},"300":{"body":125,"breadcrumbs":11,"title":3},"301":{"body":44,"breadcrumbs":10,"title":2},"302":{"body":65,"breadcrumbs":11,"title":3},"303":{"body":2,"breadcrumbs":9,"title":1},"304":{"body":94,"breadcrumbs":11,"title":3},"305":{"body":0,"breadcrumbs":11,"title":3},"306":{"body":91,"breadcrumbs":9,"title":1},"307":{"body":1,"breadcrumbs":9,"title":1},"308":{"body":1,"breadcrumbs":9,"title":1},"309":{"body":1,"breadcrumbs":11,"title":3},"31":{"body":14,"breadcrumbs":6,"title":1},"310":{"body":21,"breadcrumbs":10,"title":2},"311":{"body":74,"breadcrumbs":12,"title":4},"312":{"body":72,"breadcrumbs":8,"title":4},"313":{"body":165,"breadcrumbs":5,"title":1},"314":{"body":189,"breadcrumbs":5,"title":1},"315":{"body":86,"breadcrumbs":5,"title":1},"316":{"body":69,"breadcrumbs":7,"title":3},"317":{"body":29,"breadcrumbs":5,"title":1},"318":{"body":106,"breadcrumbs":5,"title":1},"319":{"body":143,"breadcrumbs":6,"title":2},"32":{"body":4,"breadcrumbs":8,"title":3},"320":{"body":222,"breadcrumbs":6,"title":2},"321":{"body":401,"breadcrumbs":6,"title":2},"322":{"body":87,"breadcrumbs":7,"title":3},"323":{"body":152,"breadcrumbs":6,"title":2},"324":{"body":196,"breadcrumbs":8,"title":4},"325":{"body":101,"breadcrumbs":6,"title":2},"326":{"body":6,"breadcrumbs":5,"title":1},"327":{"body":92,"breadcrumbs":7,"title":3},"328":{"body":0,"breadcrumbs":7,"title":3},"329":{"body":25,"breadcrumbs":5,"title":1},"33":{"body":14,"breadcrumbs":7,"title":2},"330":{"body":28,"breadcrumbs":6,"title":2},"331":{"body":48,"breadcrumbs":7,"title":3},"332":{"body":1,"breadcrumbs":6,"title":2},"333":{"body":68,"breadcrumbs":8,"title":4},"334":{"body":48,"breadcrumbs":12,"title":6},"335":{"body":11,"breadcrumbs":7,"title":1},"336":{"body":166,"breadcrumbs":7,"title":1},"337":{"body":6,"breadcrumbs":7,"title":1},"338":{"body":85,"breadcrumbs":7,"title":1},"339":{"body":18,"breadcrumbs":7,"title":1},"34":{"body":23,"breadcrumbs":9,"title":4},"340":{"body":4,"breadcrumbs":9,"title":3},"341":{"body":15,"breadcrumbs":9,"title":3},"342":{"body":2,"breadcrumbs":7,"title":1},"343":{"body":13,"breadcrumbs":7,"title":1},"344":{"body":16,"breadcrumbs":7,"title":1},"345":{"body":9,"breadcrumbs":9,"title":3},"346":{"body":1,"breadcrumbs":8,"title":2},"347":{"body":13,"breadcrumbs":10,"title":4},"348":{"body":45,"breadcrumbs":16,"title":8},"349":{"body":10,"breadcrumbs":9,"title":1},"35":{"body":59,"breadcrumbs":22,"title":11},"350":{"body":156,"breadcrumbs":9,"title":1},"351":{"body":4,"breadcrumbs":9,"title":1},"352":{"body":0,"breadcrumbs":9,"title":1},"353":{"body":1723,"breadcrumbs":11,"title":3},"354":{"body":52,"breadcrumbs":9,"title":1},"355":{"body":12,"breadcrumbs":9,"title":1},"356":{"body":10,"breadcrumbs":10,"title":2},"357":{"body":71,"breadcrumbs":10,"title":2},"358":{"body":26,"breadcrumbs":10,"title":2},"359":{"body":54,"breadcrumbs":14,"title":7},"36":{"body":13,"breadcrumbs":12,"title":1},"360":{"body":68,"breadcrumbs":8,"title":1},"361":{"body":87,"breadcrumbs":8,"title":1},"362":{"body":59,"breadcrumbs":8,"title":1},"363":{"body":18,"breadcrumbs":8,"title":1},"364":{"body":0,"breadcrumbs":8,"title":1},"365":{"body":64,"breadcrumbs":8,"title":1},"366":{"body":66,"breadcrumbs":8,"title":1},"367":{"body":142,"breadcrumbs":8,"title":1},"368":{"body":19,"breadcrumbs":9,"title":2},"369":{"body":104,"breadcrumbs":9,"title":2},"37":{"body":0,"breadcrumbs":12,"title":1},"370":{"body":151,"breadcrumbs":9,"title":2},"371":{"body":2,"breadcrumbs":8,"title":1},"372":{"body":28,"breadcrumbs":10,"title":3},"373":{"body":7,"breadcrumbs":9,"title":2},"374":{"body":10,"breadcrumbs":8,"title":1},"375":{"body":52,"breadcrumbs":16,"title":8},"376":{"body":16,"breadcrumbs":9,"title":1},"377":{"body":224,"breadcrumbs":9,"title":1},"378":{"body":5,"breadcrumbs":9,"title":1},"379":{"body":482,"breadcrumbs":9,"title":1},"38":{"body":37,"breadcrumbs":12,"title":1},"380":{"body":87,"breadcrumbs":9,"title":1},"381":{"body":137,"breadcrumbs":11,"title":3},"382":{"body":0,"breadcrumbs":11,"title":3},"383":{"body":23,"breadcrumbs":9,"title":1},"384":{"body":1,"breadcrumbs":9,"title":1},"385":{"body":11,"breadcrumbs":9,"title":1},"386":{"body":6,"breadcrumbs":11,"title":3},"387":{"body":1,"breadcrumbs":10,"title":2},"388":{"body":17,"breadcrumbs":12,"title":4},"389":{"body":48,"breadcrumbs":10,"title":5},"39":{"body":150,"breadcrumbs":12,"title":1},"390":{"body":65,"breadcrumbs":6,"title":1},"391":{"body":190,"breadcrumbs":6,"title":1},"392":{"body":25,"breadcrumbs":6,"title":1},"393":{"body":0,"breadcrumbs":6,"title":1},"394":{"body":367,"breadcrumbs":7,"title":2},"395":{"body":218,"breadcrumbs":7,"title":2},"396":{"body":80,"breadcrumbs":8,"title":3},"397":{"body":46,"breadcrumbs":6,"title":1},"398":{"body":23,"breadcrumbs":8,"title":3},"399":{"body":4,"breadcrumbs":7,"title":2},"4":{"body":8,"breadcrumbs":7,"title":1},"40":{"body":19,"breadcrumbs":13,"title":2},"400":{"body":48,"breadcrumbs":16,"title":8},"401":{"body":12,"breadcrumbs":9,"title":1},"402":{"body":102,"breadcrumbs":9,"title":1},"403":{"body":44,"breadcrumbs":9,"title":1},"404":{"body":58,"breadcrumbs":9,"title":1},"405":{"body":19,"breadcrumbs":9,"title":1},"406":{"body":40,"breadcrumbs":11,"title":3},"407":{"body":0,"breadcrumbs":11,"title":3},"408":{"body":15,"breadcrumbs":9,"title":1},"409":{"body":49,"breadcrumbs":10,"title":2},"41":{"body":18,"breadcrumbs":12,"title":1},"410":{"body":1,"breadcrumbs":11,"title":3},"411":{"body":62,"breadcrumbs":10,"title":2},"412":{"body":18,"breadcrumbs":12,"title":4},"413":{"body":176,"breadcrumbs":10,"title":5},"414":{"body":38,"breadcrumbs":6,"title":1},"415":{"body":34,"breadcrumbs":7,"title":2},"416":{"body":21,"breadcrumbs":8,"title":3},"417":{"body":24,"breadcrumbs":9,"title":4},"418":{"body":0,"breadcrumbs":7,"title":2},"419":{"body":10,"breadcrumbs":8,"title":3},"42":{"body":73,"breadcrumbs":12,"title":1},"420":{"body":18,"breadcrumbs":9,"title":4},"421":{"body":10,"breadcrumbs":8,"title":3},"422":{"body":46,"breadcrumbs":10,"title":5},"423":{"body":109,"breadcrumbs":8,"title":3},"424":{"body":22,"breadcrumbs":10,"title":5},"425":{"body":35,"breadcrumbs":8,"title":3},"426":{"body":16,"breadcrumbs":9,"title":4},"427":{"body":13,"breadcrumbs":9,"title":4},"428":{"body":14,"breadcrumbs":9,"title":4},"429":{"body":16,"breadcrumbs":9,"title":4},"43":{"body":2,"breadcrumbs":12,"title":1},"430":{"body":7,"breadcrumbs":9,"title":4},"431":{"body":48,"breadcrumbs":10,"title":5},"432":{"body":91,"breadcrumbs":8,"title":3},"433":{"body":104,"breadcrumbs":8,"title":3},"434":{"body":58,"breadcrumbs":9,"title":4},"435":{"body":199,"breadcrumbs":8,"title":3},"436":{"body":0,"breadcrumbs":8,"title":3},"437":{"body":313,"breadcrumbs":9,"title":4},"438":{"body":491,"breadcrumbs":10,"title":5},"439":{"body":41,"breadcrumbs":9,"title":4},"44":{"body":18,"breadcrumbs":14,"title":3},"440":{"body":146,"breadcrumbs":9,"title":4},"441":{"body":332,"breadcrumbs":9,"title":4},"442":{"body":54,"breadcrumbs":9,"title":4},"443":{"body":93,"breadcrumbs":8,"title":3},"444":{"body":75,"breadcrumbs":8,"title":3},"445":{"body":1,"breadcrumbs":7,"title":2},"446":{"body":17,"breadcrumbs":9,"title":4},"447":{"body":0,"breadcrumbs":9,"title":4},"448":{"body":32,"breadcrumbs":7,"title":2},"449":{"body":2,"breadcrumbs":7,"title":2},"45":{"body":0,"breadcrumbs":14,"title":3},"450":{"body":22,"breadcrumbs":7,"title":2},"451":{"body":25,"breadcrumbs":9,"title":4},"452":{"body":1,"breadcrumbs":8,"title":3},"453":{"body":15,"breadcrumbs":10,"title":5},"454":{"body":42,"breadcrumbs":9,"title":4},"455":{"body":19,"breadcrumbs":8,"title":3},"456":{"body":43,"breadcrumbs":10,"title":5},"457":{"body":24,"breadcrumbs":9,"title":4},"458":{"body":45,"breadcrumbs":14,"title":7},"459":{"body":22,"breadcrumbs":8,"title":1},"46":{"body":25,"breadcrumbs":12,"title":1},"460":{"body":37,"breadcrumbs":8,"title":1},"461":{"body":2,"breadcrumbs":8,"title":1},"462":{"body":202,"breadcrumbs":8,"title":1},"463":{"body":3,"breadcrumbs":8,"title":1},"464":{"body":26,"breadcrumbs":10,"title":3},"465":{"body":0,"breadcrumbs":10,"title":3},"466":{"body":8,"breadcrumbs":8,"title":1},"467":{"body":6,"breadcrumbs":8,"title":1},"468":{"body":8,"breadcrumbs":8,"title":1},"469":{"body":10,"breadcrumbs":10,"title":3},"47":{"body":4,"breadcrumbs":12,"title":1},"470":{"body":7,"breadcrumbs":9,"title":2},"471":{"body":40,"breadcrumbs":12,"title":6},"472":{"body":61,"breadcrumbs":7,"title":1},"473":{"body":101,"breadcrumbs":7,"title":1},"474":{"body":15,"breadcrumbs":7,"title":1},"475":{"body":187,"breadcrumbs":7,"title":1},"476":{"body":17,"breadcrumbs":7,"title":1},"477":{"body":12,"breadcrumbs":9,"title":3},"478":{"body":0,"breadcrumbs":9,"title":3},"479":{"body":11,"breadcrumbs":7,"title":1},"48":{"body":8,"breadcrumbs":12,"title":1},"480":{"body":40,"breadcrumbs":8,"title":2},"481":{"body":1,"breadcrumbs":9,"title":3},"482":{"body":1,"breadcrumbs":8,"title":2},"483":{"body":39,"breadcrumbs":10,"title":4},"484":{"body":61,"breadcrumbs":12,"title":6},"485":{"body":34,"breadcrumbs":7,"title":1},"486":{"body":92,"breadcrumbs":7,"title":1},"487":{"body":67,"breadcrumbs":7,"title":1},"488":{"body":4,"breadcrumbs":7,"title":1},"489":{"body":77,"breadcrumbs":7,"title":1},"49":{"body":3,"breadcrumbs":14,"title":3},"490":{"body":237,"breadcrumbs":9,"title":3},"491":{"body":124,"breadcrumbs":9,"title":3},"492":{"body":41,"breadcrumbs":9,"title":3},"493":{"body":106,"breadcrumbs":10,"title":4},"494":{"body":51,"breadcrumbs":7,"title":1},"495":{"body":27,"breadcrumbs":9,"title":3},"496":{"body":0,"breadcrumbs":9,"title":3},"497":{"body":4,"breadcrumbs":7,"title":1},"498":{"body":13,"breadcrumbs":7,"title":1},"499":{"body":3,"breadcrumbs":7,"title":1},"5":{"body":136,"breadcrumbs":7,"title":1},"50":{"body":3,"breadcrumbs":13,"title":2},"500":{"body":5,"breadcrumbs":9,"title":3},"501":{"body":2,"breadcrumbs":8,"title":2},"502":{"body":37,"breadcrumbs":10,"title":4},"503":{"body":49,"breadcrumbs":14,"title":7},"504":{"body":14,"breadcrumbs":8,"title":1},"505":{"body":113,"breadcrumbs":8,"title":1},"506":{"body":6,"breadcrumbs":8,"title":1},"507":{"body":180,"breadcrumbs":8,"title":1},"508":{"body":91,"breadcrumbs":8,"title":1},"509":{"body":25,"breadcrumbs":10,"title":3},"51":{"body":12,"breadcrumbs":15,"title":4},"510":{"body":0,"breadcrumbs":10,"title":3},"511":{"body":44,"breadcrumbs":8,"title":1},"512":{"body":13,"breadcrumbs":8,"title":1},"513":{"body":31,"breadcrumbs":8,"title":1},"514":{"body":1,"breadcrumbs":10,"title":3},"515":{"body":1,"breadcrumbs":9,"title":2},"516":{"body":12,"breadcrumbs":11,"title":4},"517":{"body":60,"breadcrumbs":10,"title":5},"518":{"body":55,"breadcrumbs":6,"title":1},"519":{"body":103,"breadcrumbs":6,"title":1},"52":{"body":65,"breadcrumbs":8,"title":4},"520":{"body":28,"breadcrumbs":6,"title":1},"521":{"body":7,"breadcrumbs":6,"title":1},"522":{"body":125,"breadcrumbs":9,"title":4},"523":{"body":83,"breadcrumbs":13,"title":8},"524":{"body":149,"breadcrumbs":10,"title":5},"525":{"body":148,"breadcrumbs":6,"title":1},"526":{"body":52,"breadcrumbs":8,"title":3},"527":{"body":0,"breadcrumbs":8,"title":3},"528":{"body":61,"breadcrumbs":6,"title":1},"529":{"body":22,"breadcrumbs":6,"title":1},"53":{"body":50,"breadcrumbs":5,"title":1},"530":{"body":6,"breadcrumbs":6,"title":1},"531":{"body":38,"breadcrumbs":6,"title":1},"532":{"body":11,"breadcrumbs":7,"title":2},"533":{"body":50,"breadcrumbs":12,"title":6},"534":{"body":37,"breadcrumbs":7,"title":1},"535":{"body":18,"breadcrumbs":7,"title":1},"536":{"body":42,"breadcrumbs":7,"title":1},"537":{"body":29,"breadcrumbs":10,"title":4},"538":{"body":29,"breadcrumbs":10,"title":4},"539":{"body":43,"breadcrumbs":7,"title":1},"54":{"body":0,"breadcrumbs":5,"title":1},"540":{"body":10,"breadcrumbs":9,"title":3},"541":{"body":0,"breadcrumbs":9,"title":3},"542":{"body":3,"breadcrumbs":7,"title":1},"543":{"body":7,"breadcrumbs":7,"title":1},"544":{"body":2,"breadcrumbs":7,"title":1},"545":{"body":14,"breadcrumbs":9,"title":3},"546":{"body":21,"breadcrumbs":8,"title":2},"55":{"body":124,"breadcrumbs":6,"title":2},"56":{"body":153,"breadcrumbs":5,"title":1},"57":{"body":90,"breadcrumbs":5,"title":1},"58":{"body":54,"breadcrumbs":5,"title":1},"59":{"body":0,"breadcrumbs":5,"title":1},"6":{"body":21,"breadcrumbs":7,"title":1},"60":{"body":438,"breadcrumbs":5,"title":1},"61":{"body":562,"breadcrumbs":5,"title":1},"62":{"body":630,"breadcrumbs":8,"title":4},"63":{"body":103,"breadcrumbs":8,"title":4},"64":{"body":410,"breadcrumbs":6,"title":2},"65":{"body":905,"breadcrumbs":6,"title":2},"66":{"body":52,"breadcrumbs":5,"title":1},"67":{"body":33,"breadcrumbs":7,"title":3},"68":{"body":40,"breadcrumbs":7,"title":3},"69":{"body":35,"breadcrumbs":8,"title":4},"7":{"body":17,"breadcrumbs":9,"title":3},"70":{"body":49,"breadcrumbs":7,"title":3},"71":{"body":34,"breadcrumbs":7,"title":3},"72":{"body":55,"breadcrumbs":8,"title":4},"73":{"body":43,"breadcrumbs":5,"title":1},"74":{"body":37,"breadcrumbs":5,"title":1},"75":{"body":73,"breadcrumbs":5,"title":1},"76":{"body":21,"breadcrumbs":5,"title":1},"77":{"body":39,"breadcrumbs":5,"title":1},"78":{"body":235,"breadcrumbs":7,"title":3},"79":{"body":86,"breadcrumbs":7,"title":3},"8":{"body":0,"breadcrumbs":9,"title":3},"80":{"body":32,"breadcrumbs":7,"title":3},"81":{"body":2,"breadcrumbs":7,"title":3},"82":{"body":11,"breadcrumbs":7,"title":3},"83":{"body":20,"breadcrumbs":8,"title":4},"84":{"body":2,"breadcrumbs":7,"title":3},"85":{"body":1,"breadcrumbs":7,"title":3},"86":{"body":53,"breadcrumbs":10,"title":5},"87":{"body":40,"breadcrumbs":6,"title":1},"88":{"body":203,"breadcrumbs":6,"title":1},"89":{"body":34,"breadcrumbs":6,"title":1},"9":{"body":39,"breadcrumbs":7,"title":1},"90":{"body":8,"breadcrumbs":6,"title":1},"91":{"body":176,"breadcrumbs":6,"title":1},"92":{"body":18,"breadcrumbs":7,"title":2},"93":{"body":11,"breadcrumbs":6,"title":1},"94":{"body":25,"breadcrumbs":8,"title":3},"95":{"body":14,"breadcrumbs":8,"title":3},"96":{"body":21,"breadcrumbs":6,"title":1},"97":{"body":16,"breadcrumbs":6,"title":1},"98":{"body":8,"breadcrumbs":6,"title":1},"99":{"body":0,"breadcrumbs":8,"title":3}},"docs":{"0":{"body":"This book contains the Polkadot Fellowship Requests for Comments (RFCs) detailing proposed changes to the technical implementation of the Polkadot network. polkadot-fellows/RFCs","breadcrumbs":"Introduction » Introduction","id":"0","title":"Introduction"},"1":{"body":"(source) Table of Contents RFC-0048: Generate ownership proof for SessionKeys Summary Motivation Stakeholders Explanation Drawbacks Testing, Security, and Privacy Performance, Ergonomics, and Compatibility Performance Ergonomics Compatibility Prior Art and References Unresolved Questions Future Directions and Related Material Start Date 13 November 2023 Description Change SessionKeys runtime api to support generating an ownership proof for the on chain registration. Authors Bastian Köcher","breadcrumbs":"RFC-0048: Generate ownership proof for SessionKeys » RFC-0048: Generate ownership proof for SessionKeys","id":"1","title":"RFC-0048: Generate ownership proof for SessionKeys"},"10":{"body":"The interfaces have been optimized to make it as easy as possible to generate the ownership proof.","breadcrumbs":"RFC-0048: Generate ownership proof for SessionKeys » Ergonomics","id":"10","title":"Ergonomics"},"100":{"body":"GitHub: Collator Selection Roadmap GitHub: Revisit Collator Selection Mechanism Polkadot Forum: Economic Model for System Para Collators","breadcrumbs":"RFC-0007: System Collator Selection » Written Discussions","id":"100","title":"Written Discussions"},"101":{"body":"Kian Paimani Jeff Burdges Rob Habermeier SR Labs Auditors Current collators including Paranodes, Stake Plus, Turboflakes, Peter Mensik, SIK, and many more.","breadcrumbs":"RFC-0007: System Collator Selection » Prior Feedback and Input From","id":"101","title":"Prior Feedback and Input From"},"102":{"body":"None at this time.","breadcrumbs":"RFC-0007: System Collator Selection » Unresolved Questions","id":"102","title":"Unresolved Questions"},"103":{"body":"There may exist in the future system chains for which this model of collator selection is not appropriate. These chains should be evaluated on a case-by-case basis.","breadcrumbs":"RFC-0007: System Collator Selection » Future Directions and Related Material","id":"103","title":"Future Directions and Related Material"},"104":{"body":"(source) Table of Contents RFC-0008: Store parachain bootnodes in relay chain DHT Summary Motivation Stakeholders Explanation DHT provider registration New networking protocol Drawbacks Testing, Security, and Privacy Performance, Ergonomics, and Compatibility Performance Ergonomics Compatibility Prior Art and References Unresolved Questions Future Directions and Related Material Start Date 2023-07-14 Description Parachain bootnodes shall register themselves in the DHT of the relay chain Authors Pierre Krieger","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » RFC-0008: Store parachain bootnodes in relay chain DHT","id":"104","title":"RFC-0008: Store parachain bootnodes in relay chain DHT"},"105":{"body":"The full nodes of the Polkadot peer-to-peer network maintain a distributed hash table (DHT), which is currently used for full nodes discovery and validators discovery purposes. This RFC proposes to extend this DHT to be used to discover full nodes of the parachains of Polkadot.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Summary","id":"105","title":"Summary"},"106":{"body":"The maintenance of bootnodes has long been an annoyance for everyone. When a bootnode is newly-deployed or removed, every chain specification must be updated in order to take the update into account. This has lead to various non-optimal solutions, such as pulling chain specifications from GitHub repositories. When it comes to RPC nodes, UX developers often have trouble finding up-to-date addresses of parachain RPC nodes. With the ongoing migration from RPC nodes to light clients, similar problems would happen with chain specifications as well. Furthermore, there exists multiple different possible variants of a certain chain specification: with the non-raw storage, with the raw storage, with just the genesis trie root hash, with or without checkpoint, etc. All of this creates confusion. Removing the need for parachain developers to be aware of and manage these different versions would be beneficial. Since the PeerId and addresses of bootnodes needs to be stable, extra maintenance work is required from the chain maintainers. For example, they need to be extra careful when migrating nodes within their infrastructure. In some situations, bootnodes are put behind domain names, which also requires maintenance work. Because the list of bootnodes in chain specifications is so annoying to modify, the consequence is that the number of bootnodes is rather low (typically between 2 and 15). In order to better resist downtimes and DoS attacks, a better solution would be to use every node of a certain chain as potential bootnode, rather than special-casing some specific nodes. While this RFC doesn't solve these problems for relay chains, it aims at solving it for parachains by storing the list of all the full nodes of a parachain on the relay chain DHT. Assuming that this RFC is implemented, and that light clients are used, deploying a parachain wouldn't require more work than registering it onto the relay chain and starting the collators. There wouldn't be any need for special infrastructure nodes anymore.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Motivation","id":"106","title":"Motivation"},"107":{"body":"This RFC has been opened on my own initiative because I think that this is a good technical solution to a usability problem that many people are encountering and that they don't realize can be solved.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Stakeholders","id":"107","title":"Stakeholders"},"108":{"body":"The content of this RFC only applies for parachains and parachain nodes that are \"Substrate-compatible\". It is in no way mandatory for parachains to comply to this RFC. Note that \"Substrate-compatible\" is very loosely defined as \"implements the same mechanisms and networking protocols as Substrate\". The author of this RFC believes that \"Substrate-compatible\" should be very precisely specified, but there is controversy on this topic. While a lot of this RFC concerns the implementation of parachain nodes, it makes use of the resources of the Polkadot chain, and as such it is important to describe them in the Polkadot specification. This RFC adds two mechanisms: a registration in the DHT, and a new networking protocol.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Explanation","id":"108","title":"Explanation"},"109":{"body":"This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot. You can find a link to the specification here . Full nodes of a parachain registered on Polkadot should register themselves onto the Polkadot DHT as the providers of a key corresponding to the parachain that they are serving, as described in the Content provider advertisement section of the specification. This uses the ADD_PROVIDER system of libp2p-kademlia. This key is: sha256(concat(scale_compact(para_id), randomness)) where the value of randomness can be found in the randomness field when calling the BabeApi_currentEpoch function. For example, for a para_id equal to 1000, and at the time of writing of this RFC (July 14th 2023 at 09:13 UTC), it is sha(0xa10f12872447958d50aa7b937b0106561a588e0e2628d33f81b5361b13dbcf8df708), which is equal to 0x483dd8084d50dbbbc962067f216c37b627831d9339f5a6e426a32e3076313d87. In order to avoid downtime when the key changes, parachain full nodes should also register themselves as a secondary key that uses a value of randomness equal to the randomness field when calling BabeApi_nextEpoch. Implementers should be aware that their implementation of Kademlia might already hash the key before XOR'ing it. The key is not meant to be hashed twice. The compact SCALE encoding has been chosen in order to avoid problems related to the number of bytes and endianness of the para_id.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » DHT provider registration","id":"109","title":"DHT provider registration"},"11":{"body":"Introduces a new version of the SessionKeys runtime api. Thus, nodes should be updated before a runtime is enacted that contains these changes otherwise they will fail to generate session keys. The RPC that exists around this runtime api needs to be updated to support passing the account id and for returning the ownership proof alongside the public session keys. UIs would need to be updated to support the new RPC and the changed on chain logic.","breadcrumbs":"RFC-0048: Generate ownership proof for SessionKeys » Compatibility","id":"11","title":"Compatibility"},"110":{"body":"A new request-response protocol should be added, whose name is /91b171bb158e2d3848fa23a9f1c25182fb8e20313b2c1eb49219da7a70ce90c3/paranode (that hexadecimal number is the genesis hash of the Polkadot chain, and should be adjusted appropriately for Kusama and others). The request consists in a SCALE-compact-encoded para_id. For example, for a para_id equal to 1000, this is 0xa10f. Note that because this is a request-response protocol, the request is always prefixed with its length in bytes. While the body of the request is simply the SCALE-compact-encoded para_id, the data actually sent onto the substream is both the length and body. The response consists in a protobuf struct, defined as: syntax = \"proto2\"; message Response { // Peer ID of the node on the parachain side. bytes peer_id = 1; // Multiaddresses of the parachain side of the node. The list and format are the same as for the `listenAddrs` field of the `identify` protocol. repeated bytes addrs = 2; // Genesis hash of the parachain. Used to determine the name of the networking protocol to connect to the parachain. Untrusted. bytes genesis_hash = 3; // So-called \"fork ID\" of the parachain. Used to determine the name of the networking protocol to connect to the parachain. Untrusted. optional string fork_id = 4;\n}; The maximum size of a response is set to an arbitrary 16kiB. The responding side should make sure to conform to this limit. Given that fork_id is typically very small and that the only variable-length field is addrs, this is easily achieved by limiting the number of addresses. Implementers should be aware that addrs might be very large, and are encouraged to limit the number of addrs to an implementation-defined value.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » New networking protocol","id":"110","title":"New networking protocol"},"111":{"body":"The peer_id and addrs fields are in theory not strictly needed, as the PeerId and addresses could be always equal to the PeerId and addresses of the node being registered as the provider and serving the response. However, the Cumulus implementation currently uses two different networking stacks, one of the parachain and one for the relay chain, using two separate PeerIds and addresses, and as such the PeerId and addresses of the other networking stack must be indicated. Asking them to use only one networking stack wouldn't feasible in a realistic time frame. The values of the genesis_hash and fork_id fields cannot be verified by the requester and are expected to be unused at the moment. Instead, a client that desires connecting to a parachain is expected to obtain the genesis hash and fork ID of the parachain from the parachain chain specification. These fields are included in the networking protocol nonetheless in case an acceptable solution is found in the future, and in order to allow use cases such as discovering parachains in a not-strictly-trusted way.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Drawbacks","id":"111","title":"Drawbacks"},"112":{"body":"Because not all nodes want to be used as bootnodes, implementers are encouraged to provide a way to disable this mechanism. However, it is very much encouraged to leave this mechanism on by default for all parachain nodes. This mechanism doesn't add or remove any security by itself, as it relies on existing mechanisms. However, if the principle of chain specification bootnodes is entirely replaced with the mechanism described in this RFC (which is the objective), then it becomes important whether the mechanism in this RFC can be abused in order to make a parachain unreachable. Due to the way Kademlia works, it would become the responsibility of the 20 Polkadot nodes whose sha256(peer_id) is closest to the key (described in the explanations section) to store the list of bootnodes of each parachain. Furthermore, when a large number of providers (here, a provider is a bootnode) are registered, only the providers closest to the key are kept, up to a certain implementation-defined limit. For this reason, an attacker can abuse this mechanism by randomly generating libp2p PeerIds until they find the 20 entries closest to the key representing the target parachain. They are then in control of the parachain bootnodes. Because the key changes periodically and isn't predictable, and assuming that the Polkadot DHT is sufficiently large, it is not realistic for an attack like this to be maintained in the long term. Furthermore, parachain clients are expected to cache a list of known good nodes on their disk. If the mechanism described in this RFC went down, it would only prevent new nodes from accessing the parachain, while clients that have connected before would not be affected.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Testing, Security, and Privacy","id":"112","title":"Testing, Security, and Privacy"},"113":{"body":"","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Performance, Ergonomics, and Compatibility","id":"113","title":"Performance, Ergonomics, and Compatibility"},"114":{"body":"The DHT mechanism generally has a low overhead, especially given that publishing providers is done only every 24 hours. Doing a Kademlia iterative query then sending a provider record shouldn't take more than around 50 kiB in total of bandwidth for the parachain bootnode. Assuming 1000 parachain full nodes, the 20 Polkadot full nodes corresponding to a specific parachain will each receive a sudden spike of a few megabytes of networking traffic when the key rotates. Again, this is relatively negligible. If this becomes a problem, one can add a random delay before a parachain full node registers itself to be the provider of the key corresponding to BabeApi_next_epoch. Maybe the biggest uncertainty is the traffic that the 20 Polkadot full nodes will receive from light clients that desire knowing the bootnodes of a parachain. Light clients are generally encouraged to cache the peers that they use between restarts, so they should only query these 20 Polkadot full nodes at their first initialization. If this every becomes a problem, this value of 20 is an arbitrary constant that can be increased for more redundancy.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Performance","id":"114","title":"Performance"},"115":{"body":"Irrelevant.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Ergonomics","id":"115","title":"Ergonomics"},"116":{"body":"Irrelevant.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Compatibility","id":"116","title":"Compatibility"},"117":{"body":"None.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Prior Art and References","id":"117","title":"Prior Art and References"},"118":{"body":"While it fundamentally doesn't change much to this RFC, using BabeApi_currentEpoch and BabeApi_nextEpoch might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet?","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Unresolved Questions","id":"118","title":"Unresolved Questions"},"119":{"body":"It is possible that in the future a client could connect to a parachain without having to rely on a trusted parachain specification.","breadcrumbs":"RFC-0008: Store parachain bootnodes in relay chain DHT » Future Directions and Related Material","id":"119","title":"Future Directions and Related Material"},"12":{"body":"None.","breadcrumbs":"RFC-0048: Generate ownership proof for SessionKeys » Prior Art and References","id":"12","title":"Prior Art and References"},"120":{"body":"(source) Table of Contents RFC-0010: Burn Coretime Revenue Summary Motivation Stakeholders Explanation Start Date 19.07.2023 Description Revenue from Coretime sales should be burned Authors Jonas Gehrlein","breadcrumbs":"RFC-0010: Burn Coretime Revenue » RFC-0010: Burn Coretime Revenue","id":"120","title":"RFC-0010: Burn Coretime Revenue"},"121":{"body":"The Polkadot UC will generate revenue from the sale of available Coretime. The question then arises: how should we handle these revenues? Broadly, there are two reasonable paths – burning the revenue and thereby removing it from total issuance or divert it to the Treasury. This Request for Comment (RFC) presents arguments favoring burning as the preferred mechanism for handling revenues from Coretime sales.","breadcrumbs":"RFC-0010: Burn Coretime Revenue » Summary","id":"121","title":"Summary"},"122":{"body":"How to handle the revenue accrued from Coretime sales is an important economic question that influences the value of DOT and should be properly discussed before deciding for either of the options. Now is the best time to start this discussion.","breadcrumbs":"RFC-0010: Burn Coretime Revenue » Motivation","id":"122","title":"Motivation"},"123":{"body":"Polkadot DOT token holders.","breadcrumbs":"RFC-0010: Burn Coretime Revenue » Stakeholders","id":"123","title":"Stakeholders"},"124":{"body":"This RFC discusses potential benefits of burning the revenue accrued from Coretime sales instead of diverting them to Treasury. Here are the following arguments for it. It's in the interest of the Polkadot community to have a consistent and predictable Treasury income, because volatility in the inflow can be damaging, especially in situations when it is insufficient. As such, this RFC operates under the presumption of a steady and sustainable Treasury income flow, which is crucial for the Polkadot community's stability. The assurance of a predictable Treasury income, as outlined in a prior discussion here , or through other equally effective measures, serves as a baseline assumption for this argument. Consequently, we need not concern ourselves with this particular issue here. This naturally begs the question - why should we introduce additional volatility to the Treasury by aligning it with the variable Coretime sales? It's worth noting that Coretime revenues often exhibit an inverse relationship with periods when Treasury spending should ideally be ramped up. During periods of low Coretime utilization (indicated by lower revenue), Treasury should spend more on projects and endeavours to increase the demand for Coretime. This pattern underscores that Coretime sales, by their very nature, are an inconsistent and unpredictable source of funding for the Treasury. Given the importance of maintaining a steady and predictable inflow, it's unnecessary to rely on another volatile mechanism. Some might argue that we could have both: a steady inflow (from inflation) and some added bonus from Coretime sales, but burning the revenue would offer further benefits as described below. Balancing Inflation: While DOT as a utility token inherently profits from a (reasonable) net inflation, it also benefits from a deflationary force that functions as a counterbalance to the overall inflation. Right now, the only mechanism on Polkadot that burns fees is the one for underutilized DOT in the Treasury. Finding other, more direct target for burns makes sense and the Coretime market is a good option. Clear incentives: By burning the revenue accrued on Coretime sales, prices paid by buyers are clearly costs. This removes distortion from the market that might arise when the paid tokens occur on some other places within the network. In that case, some actors might have secondary motives of influencing the price of Coretime sales, because they benefit down the line. For example, actors that actively participate in the Coretime sales are likely to also benefit from a higher Treasury balance, because they might frequently request funds for their projects. While those effects might appear far-fetched, they could accumulate. Burning the revenues makes sure that the prices paid are clearly costs to the actors themselves. Collective Value Accrual: Following the previous argument, burning the revenue also generates some externality, because it reduces the overall issuance of DOT and thereby increases the value of each remaining token. In contrast to the aforementioned argument, this benefits all token holders collectively and equally. Therefore, I'd consider this as the preferrable option, because burns lets all token holders participate at Polkadot's success as Coretime usage increases.","breadcrumbs":"RFC-0010: Burn Coretime Revenue » Explanation","id":"124","title":"Explanation"},"125":{"body":"(source) Table of Contents RFC-0012: Process for Adding New System Collectives Summary Motivation Stakeholders Explanation Removing Collectives Drawbacks Testing, Security, and Privacy Performance, Ergonomics, and Compatibility Prior Art and References Unresolved Questions Start Date 24 July 2023 Description A process for adding new (and removing existing) system collectives. Authors Joe Petrowski","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » RFC-0012: Process for Adding New System Collectives","id":"125","title":"RFC-0012: Process for Adding New System Collectives"},"126":{"body":"Since the introduction of the Collectives parachain, many groups have expressed interest in forming new -- or migrating existing groups into -- on-chain collectives. While adding a new collective is relatively simple from a technical standpoint, the Fellowship will need to merge new pallets into the Collectives parachain for each new collective. This RFC proposes a means for the network to ratify a new collective, thus instructing the Fellowship to instate it in the runtime.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Summary","id":"126","title":"Summary"},"127":{"body":"Many groups have expressed interest in representing collectives on-chain. Some of these include: Parachain technical fellowship (new) Fellowship(s) for media, education, and evangelism (new) Polkadot Ambassador Program (existing) Anti-Scam Team (existing) Collectives that form part of the core Polkadot protocol should have a mandate to serve the Polkadot network. However, as part of the Polkadot protocol, the Fellowship, in its capacity of maintaining system runtimes, will need to include modules and configurations for each collective. Once a group has developed a value proposition for the Polkadot network, it should have a clear path to having its collective accepted on-chain as part of the protocol. Acceptance should direct the Fellowship to include the new collective with a given initial configuration into the runtime. However, the network, not the Fellowship, should ultimately decide which collectives are in the interest of the network.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Motivation","id":"127","title":"Motivation"},"128":{"body":"Polkadot stakeholders who would like to organize on-chain. Technical Fellowship, in its role of maintaining system runtimes.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Stakeholders","id":"128","title":"Stakeholders"},"129":{"body":"The group that wishes to operate an on-chain collective should publish the following information: Charter, including the collective's mandate and how it benefits Polkadot. This would be similar to the Fellowship Manifesto . Seeding recommendation. Member types, i.e. should members be individuals or organizations. Member management strategy, i.e. how do members join and get promoted, if applicable. How much, if at all, members should get paid in salary. Any special origins this Collective should have outside its self. For example, the Fellowship can whitelist calls for referenda via the WhitelistOrigin. This information could all be in a single document or, for example, a GitHub repository. After publication, members should seek feedback from the community and Technical Fellowship, and make any revisions needed. When the collective believes the proposal is ready, they should bring a remark with the text APPROVE_COLLECTIVE(\"{collective name}, {commitment}\") to a Root origin referendum. The proposer should provide instructions for generating commitment. The passing of this referendum would be unequivocal direction to the Fellowship that this collective should be part of the Polkadot runtime. Note: There is no need for a REJECT referendum. Proposals that have not been approved are simply not included in the runtime.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Explanation","id":"129","title":"Explanation"},"13":{"body":"None.","breadcrumbs":"RFC-0048: Generate ownership proof for SessionKeys » Unresolved Questions","id":"13","title":"Unresolved Questions"},"130":{"body":"If someone believes that an existing collective is not acting in the interest of the network or in accordance with its charter, they should likewise have a means to instruct the Fellowship to remove that collective from Polkadot. An on-chain remark from the Root origin with the text REMOVE_COLLECTIVE(\"{collective name}, {para ID}, [{pallet indices}]\") would instruct the Fellowship to remove the collective via the listed pallet indices on paraId. Should someone want to construct such a remark, they should have a reasonable expectation that a member of the Fellowship would help them identify the pallet indices associated with a given collective, whether or not the Fellowship member agrees with removal. Collective removal may also come with other governance calls, for example voiding any scheduled Treasury spends that would fund the given collective.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Removing Collectives","id":"130","title":"Removing Collectives"},"131":{"body":"Passing a Root origin referendum is slow. However, given the network's investment (in terms of code maintenance and salaries) in a new collective, this is an appropriate step.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Drawbacks","id":"131","title":"Drawbacks"},"132":{"body":"No impacts.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Testing, Security, and Privacy","id":"132","title":"Testing, Security, and Privacy"},"133":{"body":"Generally all new collectives will be in the Collectives parachain. Thus, performance impacts should strictly be limited to this parachain and not affect others. As the majority of logic for collectives is generalized and reusable, we expect most collectives to be instances of similar subsets of modules. That is, new collectives should generally be compatible with UIs and other services that provide collective-related functionality, with little modifications to support new ones.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Performance, Ergonomics, and Compatibility","id":"133","title":"Performance, Ergonomics, and Compatibility"},"134":{"body":"The launch of the Technical Fellowship, see the initial forum post .","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Prior Art and References","id":"134","title":"Prior Art and References"},"135":{"body":"None at this time.","breadcrumbs":"RFC-0012: Process for Adding New System Collectives » Unresolved Questions","id":"135","title":"Unresolved Questions"},"136":{"body":"(source) Table of Contents RFC-0013: Prepare Core runtime API for MBMs Summary Motivation Stakeholders Explanation Core::initialize_block Drawbacks Testing, Security, and Privacy Performance, Ergonomics, and Compatibility Performance Ergonomics Compatibility Prior Art and References Unresolved Questions Future Directions and Related Material Start Date July 24, 2023 Description Prepare the Core Runtime API for Multi-Block-Migrations Authors Oliver Tale-Yazdi","breadcrumbs":"RFC-0013: Prepare Core runtime API for MBMs » RFC-0013: Prepare Core runtime API for MBMs","id":"136","title":"RFC-0013: Prepare Core runtime API for MBMs"},"137":{"body":"Introduces breaking changes to the Core runtime API by letting Core::initialize_block return an enum. The versions of Core is bumped from 4 to 5.","breadcrumbs":"RFC-0013: Prepare Core runtime API for MBMs » Summary","id":"137","title":"Summary"},"138":{"body":"The main feature that motivates this RFC are Multi-Block-Migrations (MBM); these make it possible to split a migration over multiple blocks. Further it would be nice to not hinder the possibility of implementing a new hook poll, that runs at the beginning of the block when there are no MBMs and has access to AllPalletsWithSystem. This hook can then be used to replace the use of on_initialize and on_finalize for non-deadline critical logic. In a similar fashion, it should not hinder the future addition of a System::PostInherents callback that always runs after all inherents were applied.","breadcrumbs":"RFC-0013: Prepare Core runtime API for MBMs » Motivation","id":"138","title":"Motivation"},"139":{"body":"Substrate Maintainers: They have to implement this, including tests, audit and maintenance burden. Polkadot Runtime developers: They will have to adapt the runtime files to this breaking change. Polkadot Parachain Teams: They have to adapt to the breaking changes but then eventually have multi-block migrations available.","breadcrumbs":"RFC-0013: Prepare Core runtime API for MBMs » Stakeholders","id":"139","title":"Stakeholders"},"14":{"body":"Substrate implementation of the RFC .","breadcrumbs":"RFC-0048: Generate ownership proof for SessionKeys » Future Directions and Related Material","id":"14","title":"Future Directions and Related Material"},"140":{"body":"","breadcrumbs":"RFC-0013: Prepare Core runtime API for MBMs » Explanation","id":"140","title":"Explanation"},"141":{"body":"This runtime API function is changed from returning () to ExtrinsicInclusionMode: fn initialize_block(header: &