From 852602840665ad0340c2973cf0f63b8f709077a7 Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Wed, 16 Jul 2025 14:18:48 +0500 Subject: [PATCH 1/7] Init ADR #0012: Initial Precompiles --- docs/ADR/0012-initial-precompiles.md | 189 +++++++++++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 docs/ADR/0012-initial-precompiles.md diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md new file mode 100644 index 0000000..fb5a396 --- /dev/null +++ b/docs/ADR/0012-initial-precompiles.md @@ -0,0 +1,189 @@ +# ADR_0012: Initial Precompiles + +## Date + +Decision date: YYYY-MM-DD +Last status update: YYYY-MM-DD + +## Status + +- [ ] Proposed +- [ ] Accepted +- [ ] Deprecated +- [ ] Superseded + +### Implementation Status + +- [ ] Planned +- [ ] In Development +- [ ] Implemented +- [ ] Verified +- [ ] Discontinued + +## People + +### Author/Decision Owner + +- Alisher Khassanov, [@khssnv](https://github.com/khssnv) + +### Consulted (Subject Matter Experts) + +[List of people with relevant expertise who provided advice] + +- [Person 1] +- [Person 2] +- [Person 3] + +### Informed (Affected Parties) + +[People/teams affected by this decision who should be aware] + +- [ ] [Person 1] +- [ ] [Person 2] +- [ ] [Person 3] + +*Note: People listed in "Informed" should submit a PR to check their name after reading this ADR. This can be done during the initial review process of the ADR upload/commit PR (when the file is first uploaded to GitHub and the author requests reviews), or in a separate PR after the ADR is merged.* + +## Decision + +[Briefly describe the decision made in "We will..." format. This section should be concise - it's a declaration of intent for implementers. Detailed reasoning belongs in other sections.] + +## Context + +[Describe the situation that calls for a decision. Focus on forces, constraints, and circumstances that led to needing this decision. Answer "What is the problem?" not "What's the solution?" Include: + +- Technical, business, and organizational context +- Applicable requirements (functional and cross-functional) +- Current state and why change is needed +- Key stakeholders and their concerns] + +### Decision Criteria (Optional) + +[Explicit criteria for evaluating options, such as: + +- Performance requirements +- Cost constraints +- Security requirements +- Maintainability needs +- Time-to-market considerations] + +## Problem (Optional) + +[Clearly state the problem being addressed. What issue or opportunity requires this architectural decision?] + +## Decision in Details (Optional) + +[Describe in details the decision made, including: + +- Key technical details +- Implementation approach +- Timeline considerations +- Who is responsible for implementation] + +### Decision Drivers (Optional) + +- [Driver 1: Key force or requirement influencing the decision] +- [Driver 2: Another key consideration] +- [...] + +## Options + +[Briefly list the considered options. Each option is numbered for easy reference, with the selected option marked clearly as `(SELECTED)`. Aim for 3-5 options minimum. Always include at least "do nothing" option. A detailed description of each option can be written in the Consequences section below.] + +1. (SELECTED) [Name of selected option] +2. [Name of alternative option] +3. [Name of alternative option] +4. [Do nothing / Status quo option] + +## Consequences (Optional) + +### Option 1: [Name of option] (SELECTED) + +[Brief description of this option.] + +**Selected because:** + +- [Benefit 1 that led to selection] +- [Benefit 2 that led to selection] + +**Selected despite:** + +- [Drawback 1 that we accept] +- [Drawback 2 that we accept] + +**Risks and Mitigations:** + +- [Risk 1] + - [Mitigation strategy 1] +- [Risk 2] + - [Mitigation strategy 2] + +**Failure Recovery:** +[How will we recover if this option fails?] + +### Option 2: [Name of alternative option] + +[Brief description of this option.] + +**Rejected because:** + +- [Critical drawback 1 - reason for rejection] +- [Critical drawback 2 - reason for rejection] + +**Rejected despite:** + +- [Potential benefit 1 we're giving up] +- [Potential benefit 2 we're giving up] + +*(Repeat for additional options if applicable)* + +## Implementation Notes (Optional) + +[Any specific guidance for implementing this decision, including: + +- Required dependencies +- Migration steps +- Testing considerations +- Failure Recovery / Rollback procedures] + +## Confirmation (Optional) + +[Describe how the implementation of this decision will be verified. Include: + +- Acceptance criteria +- Testing approach +- Automated verification methods] + +## Advice (Optional) + +[Raw, unfiltered contributions from people who offered advice. his section provides transparency into the decision process and serves as a learning resource.] + +- [Advice given] ([Advice-giver's name, role], YYYY-MM-DD) +- [Advice given] ([Advice-giver's name, role], YYYY-MM-DD) + +## Glossary (Optional) + +- **[Term]**: [Definition] + +## References + +- [Related documents, links, and research materials] +- [Previous ADRs that influence this decision] +- [External resources that informed this decision] +- [Requirements or standards] + +## ADR Relationships + +[Fill in the section if applicable or leave blank for further filling.] + +### Supersedes + +- ADR #[X]: [Brief description of superseded decision] + +### Superseded By + +- ADR #[X]: [Brief description of superseding decision] + +### Related ADRs + +- ADR #[X]: [Brief description of relationship] From 15745a98aabf418cc4176ea9e186000ec1c69725 Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Wed, 16 Jul 2025 15:58:02 +0500 Subject: [PATCH 2/7] Initial precompiles ideas --- docs/ADR/0012-initial-precompiles.md | 126 +++++---------------------- 1 file changed, 22 insertions(+), 104 deletions(-) diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md index fb5a396..3520fa3 100644 --- a/docs/ADR/0012-initial-precompiles.md +++ b/docs/ADR/0012-initial-precompiles.md @@ -7,14 +7,14 @@ Last status update: YYYY-MM-DD ## Status -- [ ] Proposed +- [x] Proposed - [ ] Accepted - [ ] Deprecated - [ ] Superseded ### Implementation Status -- [ ] Planned +- [x] Planned - [ ] In Development - [ ] Implemented - [ ] Verified @@ -26,77 +26,16 @@ Last status update: YYYY-MM-DD - Alisher Khassanov, [@khssnv](https://github.com/khssnv) -### Consulted (Subject Matter Experts) +### Consulted -[List of people with relevant expertise who provided advice] - -- [Person 1] -- [Person 2] -- [Person 3] - -### Informed (Affected Parties) - -[People/teams affected by this decision who should be aware] - -- [ ] [Person 1] -- [ ] [Person 2] -- [ ] [Person 3] - -*Note: People listed in "Informed" should submit a PR to check their name after reading this ADR. This can be done during the initial review process of the ADR upload/commit PR (when the file is first uploaded to GitHub and the author requests reviews), or in a separate PR after the ADR is merged.* +### Informed ## Decision -[Briefly describe the decision made in "We will..." format. This section should be concise - it's a declaration of intent for implementers. Detailed reasoning belongs in other sections.] - -## Context - -[Describe the situation that calls for a decision. Focus on forces, constraints, and circumstances that led to needing this decision. Answer "What is the problem?" not "What's the solution?" Include: - -- Technical, business, and organizational context -- Applicable requirements (functional and cross-functional) -- Current state and why change is needed -- Key stakeholders and their concerns] - -### Decision Criteria (Optional) - -[Explicit criteria for evaluating options, such as: - -- Performance requirements -- Cost constraints -- Security requirements -- Maintainability needs -- Time-to-market considerations] - -## Problem (Optional) - -[Clearly state the problem being addressed. What issue or opportunity requires this architectural decision?] - -## Decision in Details (Optional) - -[Describe in details the decision made, including: - -- Key technical details -- Implementation approach -- Timeline considerations -- Who is responsible for implementation] - -### Decision Drivers (Optional) - -- [Driver 1: Key force or requirement influencing the decision] -- [Driver 2: Another key consideration] -- [...] +We will create a set of initial precompiles for the smart contracts platform. ## Options -[Briefly list the considered options. Each option is numbered for easy reference, with the selected option marked clearly as `(SELECTED)`. Aim for 3-5 options minimum. Always include at least "do nothing" option. A detailed description of each option can be written in the Consequences section below.] - -1. (SELECTED) [Name of selected option] -2. [Name of alternative option] -3. [Name of alternative option] -4. [Do nothing / Status quo option] - -## Consequences (Optional) - ### Option 1: [Name of option] (SELECTED) [Brief description of this option.] @@ -121,38 +60,34 @@ Last status update: YYYY-MM-DD **Failure Recovery:** [How will we recover if this option fails?] -### Option 2: [Name of alternative option] +### Option 2: Expose governance functionality to smart contracts -[Brief description of this option.] +See . **Rejected because:** -- [Critical drawback 1 - reason for rejection] -- [Critical drawback 2 - reason for rejection] +- Implementation already taken by Polkadot Technical Fellowship member. **Rejected despite:** - [Potential benefit 1 we're giving up] - [Potential benefit 2 we're giving up] -*(Repeat for additional options if applicable)* +### Option 3: ERC721, ERC1155 for `pallet-nfts` -## Implementation Notes (Optional) +**Rejected because:** -[Any specific guidance for implementing this decision, including: +- Not related to QF Network priorities. -- Required dependencies -- Migration steps -- Testing considerations -- Failure Recovery / Rollback procedures] +### Option 4: Utility pallets interface -## Confirmation (Optional) +- `pallet-scheduler` for scheduling runtime calls to occur at a specified block number or at a specified period. +- `pallet-multisig` to access existing multisig functionality from a smart contract. +- `pallet-indices` for smart contracts to be able to use short form address. -[Describe how the implementation of this decision will be verified. Include: +### Option 5: XCM precompile -- Acceptance criteria -- Testing approach -- Automated verification methods] +- Proxy to Ethereum smart contracts. Data availability restrictions. ## Advice (Optional) @@ -161,29 +96,12 @@ Last status update: YYYY-MM-DD - [Advice given] ([Advice-giver's name, role], YYYY-MM-DD) - [Advice given] ([Advice-giver's name, role], YYYY-MM-DD) -## Glossary (Optional) +## Glossary -- **[Term]**: [Definition] +- **Precompile**: runtime function available to smart contracts via a cross-contract call. ## References -- [Related documents, links, and research materials] -- [Previous ADRs that influence this decision] -- [External resources that informed this decision] -- [Requirements or standards] - -## ADR Relationships - -[Fill in the section if applicable or leave blank for further filling.] - -### Supersedes - -- ADR #[X]: [Brief description of superseded decision] - -### Superseded By - -- ADR #[X]: [Brief description of superseding decision] - -### Related ADRs - -- ADR #[X]: [Brief description of relationship] +- Revive project review, . +- How precompiles work, . +- Governance for modifying precompiles set, . From 29d1635f9bb38d63a1ce9a0f3427ff68244729b6 Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Fri, 18 Jul 2025 11:46:13 +0500 Subject: [PATCH 3/7] Update docs/ADR/0012-initial-precompiles.md Co-authored-by: AlexLgn <163022590+AlexLgn@users.noreply.github.com> --- docs/ADR/0012-initial-precompiles.md | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md index 3520fa3..106cb6d 100644 --- a/docs/ADR/0012-initial-precompiles.md +++ b/docs/ADR/0012-initial-precompiles.md @@ -89,12 +89,28 @@ See . - Proxy to Ethereum smart contracts. Data availability restrictions. -## Advice (Optional) - -[Raw, unfiltered contributions from people who offered advice. his section provides transparency into the decision process and serves as a learning resource.] - -- [Advice given] ([Advice-giver's name, role], YYYY-MM-DD) -- [Advice given] ([Advice-giver's name, role], YYYY-MM-DD) +## Advice + +- I would not focus on NFTs. The NFTs currently are not hype at all. I don't see this adding much value (Memechi Kekamoto, 2025-07-17) +- Explore account abstraction or other standards... like ERC-4337... to enable an AI-agent or other entity to control tokens, allowing them to be spent freely without signing additional transactions or requiring extra user input (Memechi Kekamoto, 2025-07-17) +- This ERC is 7857 (Sviatoslav Alekseev, 2025-07-17) +- Regarding account abstraction, this might be a nice-to-have thing and would require some further research (Memechi Kekamoto, 2025-07-17) +- Consider precompiles for utility pallets like `pallet-scheduler`, `pallet-multisig`, and `pallet-indices`, as they are pretty useful (Memechi Kekamoto, 2025-07-17) +- I definitely want to put somewhere some form of randomness whether it's via oracle or via internal pallet. I think that would be very cool (Memechi Kekamoto, 2025-07-17) +- Pyth provide data to all the like 50 or more blockchains and super cheap, super good (Memechi Kekamoto, 2025-07-17) +- Pyth not only provides information about prices but things like PolyMarket and many other Web2 things... If we can have this exposed somehow as a precompile, I believe this is a big added value to the whole ecosystem (Memechi Kekamoto, 2025-07-17) +- For Pyth, you just need u someone to put the data from their network to our blockchain and we will be able to access it just to through the storage (Sviatoslav Alekseev, 2025-07-17) +- Maybe there are parachains that provide decentralized oracle network feature? (Memechi Kekamoto, 2025-07-17) +- I think we all agree that having some form of oracle access inside the smart contract is very useful (Memechi Kekamoto, 2025-07-17) +- This XCM functionality is very cool functionality and in theory this could be later expanded to more blockchains or be built better (Memechi Kekamoto, 2025-07-17) +- Pyth also provide [entropy](https://docs.pyth.network/entropy). Pyth Entropy allows developers to quickly and easily generate secure random numbers on the blockchain (Sviatoslav Alekseev, 2025-07-17) +- There is also insecure randomness in Polkadot and we can also implement the precompile for it (Alisher Khassanov, 2025-07-17) +- I think insecure randomness is a good starting point (Memechi Kekamoto, 2025-07-17) +- Explore a REST-like storage for precompile ... provide an interface for easy access to storage with methods like update, delete as it is easy to understand for an inter developer (Memechi Kekamoto, 2025-07-17) +- Randomness could be [quantum ](https://aws.amazon.com/marketplace/pp/prodview-246kyrfjo3bag) (Alex Vyatkin, 2025-07-17) +- From an implementation standpoint, it's best to go from easiest to implement towards harder to implement to have a starting set (Memechi Kekamoto, 2025-07-17) +- Go through ideas of the SDK brainstorm and maybe add something from that to the ADR (Memechi Kekamoto, 2025-07-17) +- Question the need for a precompile for payment logic abstraction, as existing functions (account, transfer, check balance) allow developers to write this directly in smart contracts (Memechi Kekamoto, 2025-07-17) ## Glossary From ebb052c78e36d0c7c295b314f534291c06d4db8f Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Fri, 18 Jul 2025 18:41:46 +0500 Subject: [PATCH 4/7] Add advised options --- docs/ADR/0012-initial-precompiles.md | 39 ++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md index 106cb6d..37483e6 100644 --- a/docs/ADR/0012-initial-precompiles.md +++ b/docs/ADR/0012-initial-precompiles.md @@ -89,6 +89,45 @@ See . - Proxy to Ethereum smart contracts. Data availability restrictions. +### Option 6: ERC-4337 Account Abstraction precompile + +As per , Account Abstraction architecture unlocks Ethereum wallet features like: + +- Custom signature schemes (e.g. passkeys, multisig). +- Gasless transactions via Paymasters. +- One-click flows through batched calls. +- Modular smart accounts with upgradability and recovery. +- Wallet creation without EOAs or upfront ETH. + +In Polkadot SDK the Origin Abstraction offers a similar set of features (see ). Further research is needed to determine use cases and the implementation form. + +For the target use case: "As a user, I want to authorize an AI agent to spend a limited amount of my tokens, so it can make purchases on my behalf" further research needed to determine the difference in case of an implementation as the Account Abstraction precompile or by other means. + +### Option 7: ERC-7857 precompile + +As per , ERC-7857 defines iNFTs which represents AI Agents and bring the following key advantages: + +- Transferability: AI agents can be freely bought, sold, or transferred between owners, with their value reflecting their capabilities and earnings. +- Full Decentralization: No longer owned and managed by a single team, iNFTs ensure decentralized control over AI agents. +- Asset Control: Owners have exclusive rights to manage and claim all assets, earnings, and gains generated by their AI agents. +- Royalties: Those creating AI-NFTs can earn a percentage of revenue every time their AI agents are resold on secondary markets. + +### Option 8: randomness source + +See advised options. + +### Option 9: oracle framework + +### Option 10: REST-like storage + +An on-chain storage with REST-like interface. + +### Option 11: Market data provider integration (Pyth) + +### Option 12: Decentralized Oracle parachain integration + +### Option 13: Payment abstraction precompile + ## Advice - I would not focus on NFTs. The NFTs currently are not hype at all. I don't see this adding much value (Memechi Kekamoto, 2025-07-17) From c8ce07c5081b63e1d6498333d1f146399e17deea Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Fri, 18 Jul 2025 18:41:57 +0500 Subject: [PATCH 5/7] Typo fix --- docs/ADR/0012-initial-precompiles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md index 37483e6..eab5535 100644 --- a/docs/ADR/0012-initial-precompiles.md +++ b/docs/ADR/0012-initial-precompiles.md @@ -146,7 +146,7 @@ An on-chain storage with REST-like interface. - There is also insecure randomness in Polkadot and we can also implement the precompile for it (Alisher Khassanov, 2025-07-17) - I think insecure randomness is a good starting point (Memechi Kekamoto, 2025-07-17) - Explore a REST-like storage for precompile ... provide an interface for easy access to storage with methods like update, delete as it is easy to understand for an inter developer (Memechi Kekamoto, 2025-07-17) -- Randomness could be [quantum ](https://aws.amazon.com/marketplace/pp/prodview-246kyrfjo3bag) (Alex Vyatkin, 2025-07-17) +- Randomness could be [quantum](https://aws.amazon.com/marketplace/pp/prodview-246kyrfjo3bag) (Alex Vyatkin, 2025-07-17) - From an implementation standpoint, it's best to go from easiest to implement towards harder to implement to have a starting set (Memechi Kekamoto, 2025-07-17) - Go through ideas of the SDK brainstorm and maybe add something from that to the ADR (Memechi Kekamoto, 2025-07-17) - Question the need for a precompile for payment logic abstraction, as existing functions (account, transfer, check balance) allow developers to write this directly in smart contracts (Memechi Kekamoto, 2025-07-17) From d3f11fd7cb5c3a4d8b43440778aae4569b378853 Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Mon, 21 Jul 2025 17:15:18 +0500 Subject: [PATCH 6/7] Add `pallet-preimage` precompile --- docs/ADR/0012-initial-precompiles.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md index eab5535..d6980cb 100644 --- a/docs/ADR/0012-initial-precompiles.md +++ b/docs/ADR/0012-initial-precompiles.md @@ -84,6 +84,7 @@ See . - `pallet-scheduler` for scheduling runtime calls to occur at a specified block number or at a specified period. - `pallet-multisig` to access existing multisig functionality from a smart contract. - `pallet-indices` for smart contracts to be able to use short form address. +- `pallet-preimage` for storing byte-blobs. ### Option 5: XCM precompile From 38deee81325ba06e27b76863495205e45f398b17 Mon Sep 17 00:00:00 2001 From: "Alisher A. Khassanov" Date: Wed, 23 Jul 2025 16:00:02 +0500 Subject: [PATCH 7/7] Add randomness precompile options --- docs/ADR/0012-initial-precompiles.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/ADR/0012-initial-precompiles.md b/docs/ADR/0012-initial-precompiles.md index d6980cb..74e446a 100644 --- a/docs/ADR/0012-initial-precompiles.md +++ b/docs/ADR/0012-initial-precompiles.md @@ -115,7 +115,9 @@ As per , ERC-7857 defines iNFTs whic ### Option 8: randomness source -See advised options. +- `pallet-insecure-randomness-collective-flip` precompile. +- Centralized source oracle. +- Moonbeam Randomness Precompile, see . ### Option 9: oracle framework