w3f/psps

Polkadot Smart Contract Proposals

Polkadot Smart Contract Proposals (PSPs)

A Polkadot Smart Contract Proposal (PSP) describes standards for smart contracts in the Polkadot ecosystem. The Polkadot Smart Contract Proposal GitHub is a community-based initiative. The PSP process is not supposed to be a substitute for the Polkadot Governance process or the RFCs process.

Disclaimer: The Polkadot Standards Proposals have been renamed to Polkadot Smart Contract Proposals (PSPs). Everything else should be discussed as part of the RFCs process.

---

• 📋 Process
• 📝 Contributing
• 💡 Help

📋 Process

Below is the workflow of a successful PSPs:

1. Draft -> 2. Call for Feedback -> 3. Published -> 4. Integrated

1. Draft: A valid draft, which is merged into the draft subfolder and actively improved together with the community.
2. Call for Feedback: The PSP will be shared on different public channels for additional feedback for at least two weeks. The result of this step is either an acceptance of the standard (->Published) or a rejection (->Draft).
3. Published: Any further changes are unlikely, and developers can start integrating the PSP.
4. Integrated: The PSP is actively used, and a reference implementation exists.

In order to be merged or accepted for the different stages, reviewers need to approve a PR. Reviewers should be known experts in the topic covered by the PSP.

📝 Contributing

Before you start writing a formal PSP, you should discuss an idea in the various community public channels (see the Polkadot community website). A PSP should provide the motivation as well as a technical specification for the feature.

1. Fork this repository.
2. In the newly created fork, create a copy of the template.
3. Fill out the template with the details of your PSP. If your PSP requires images, the images should be integrated into a subdirectory of the src folder, which has your PSP number as the name.
4. Once you have completed the application, click on "create new pull request".
5. Rename the file with "psp-number_of_your_pr.md".
6. Update the pull request.

💡 Help

• GitHub Discussions
• PSP Channel on Element

psps's Issues

Do I need to propose a standard here?

Hi @Noc2, I am very happy to say that my work has basically been completed, but after the development is complete, the initial Sub NFT has become a multifunctional NFT. It includes batch minting/transfer, token combination method and splite method. In addition, I also added a reference to moloch's DAO, but you can use nft as a tribute. Do I need to mention here Is the multifunctional NFT standard part of Grant? Or is it just a token split standard?

PSP for JS extension API

We currently have https://github.com/polkadot-js/extension/ that implements an API to allow dApp to communicate with wallets.
It will be good if we can standardize it to allow future extension to support features such as Proxy or Multisig.

PSP34 optional extension for enumerable collections

Most of NFT collections are enumerable. I think functions relevant for enumerable collections should be added to PSP34 as optional extension, like it done in ERC721Enumerable.

ERC721Enumerable standard includes the following functions:

totalSupply() external view returns (uint256);
tokenByIndex(uint256 _index) external view returns (uint256);
tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);

PSP6 is extremely poor, technically speaking

PSP6, introduced in #6, specified a list of JSON-RPC functions by simply copy-pasting the ones that are currently in use.

The problem is that nobody (at Parity or outside) has actually really ever worked on polishing these JSON-RPC functions. They were added at will, accepting every Substrate PR that adds or touches a function without really thinking about it.

The consequence is that these JSON-RPC functions have a lot of defects. Rather than copy-paste a list of defects, I'm going to link to the first section of this hackmd that I wrote a long time ago: https://hackmd.io/fvwtpwrVTg-fUScreohOsw
Of course some points regarding documentation do not apply because you did a great job documenting the format of the functions, but documenting the functions doesn't remove most of the core issues in them.

One of the major issues with these JSON-RPC functions is that they can't be properly implemented by a light client. If you build a tool on top of these functions, and connect to a light client, your tool will not work properly. Some tools just can't be built on top of light clients, but most of the time it's just because the tool needs to be able to handle some corner cases that don't happen when connected to full nodes.

Having this list of JSON-RPC functions as some sort of "standard" gives the impression that we're committed to these functions, but it is very much desirable to get rid of them in the future.
Some time ago I've started https://github.com/paritytech/json-rpc-interface-spec/, which has the objective of replacing these JSON-RPC functions with better ones.

[Question] FRAME Pallet Proposals

I have written a FRAME pallet for non-fungible tokens and am looking for feedback - is this the right place to have such a discussion?

PSP -> PCP rename "breaks" all token standards

The recent rename of the whole repo from Polkadot Standards Proposals to Polkadot Contracts Proposals leaves the existing token standards (PSP22, PSP34, PSP37) in a somewhat "broken" state. These documents are named and referred from "outside" as PCPxx, while inside they still use the PSPxx naming. That turns out to be quite problematic, since these token standards define the selectors of all messages based on blake2b_256 hashes of message names prefixed with a "namespace identifier" in a form of PSPxx:: for example:

transfer(to: AccountId, value: Balance, data: [u8]) ➔ Result<(), PSP22Error>
Selector: 0xdb20f9f5 - first 4 bytes of blake2b_256("PSP22::transfer")

If the PSP -> PCP rename would be rigorously applied inside the token standards documents, it would change the values of all these selectors. The standards have already been in a Published state for quite some time and there are multiple contracts deployed to production that rely on them. Changing the standards now would be a serious breaking change and could result in severe disruptions in these projects.

On the other hand, leaving the selectors with their current values is also not ideal. The situation in which PCP22 standard defines all its methods based on PSP22:: prefix is very confusing and can potentially lead to many errors and lots of headache from smart contract developers.

Given all the above, I'd like to bring into consideration the suggestion to revert the problematic PSP -> PCP rename. It looks to me that it's a relatively cosmetic change which brings quite a lot of serious problems, and there doesn't seem to be any other easy and elegant solution.

PSP categorization schema

I've been studying the Core EIPs and got curious:

Is there any schema classifying PSPs in terms of:

• Runtime Standards: runtime logic composed by multiple pallets
• Smart Contract Standards: ABI level standards tailored for pallet-contracts or pallet-evm (which could also be another form of subcategorization)

in case there isn't, wouldn't it make sense for us to introduce some?

The rationale would be the argument that Smart Contract and Runtime are fundamentally different layers of execution under the Polkadot protocol, so it would make sense to have the PSP structure reflect that in some way or another. That would also help the audience assimilate those fundamental differences from the PSP structure itself.

The way they are structured now, the PSPs give some descriptive context, frequently on the Motivation section.
But it would be useful to help the reader assimilate inherently foundational concepts about the PSP even before they start reading it, because they already know the PSP belongs to a certain category.

Easier Navigation and Discovery

Entering this repo, i'm greeted by a long list of numbered PSPs in draft that mean nothing to me. I need to click into each individually to learn what is the topic of each

Could we make it easier to navigate by making a table of contents of sort on the main README.md?

Perhaps just

Number	Title	Authors	Status

PSP34 Transfer event parameter "from" is unnecessary

In PSP34 the Transfer event possesses field "from" that is unnecessary.

One can always deduce the previous owner of a token with an ID based on the previous Transfer event that contains the ID.
If such a previous event doesn't exist it means that the token hasn't been minted.

I would recommend changing the standard. Changes to events should not break the cross-contract calls. Also If one assumes the new standard in one's off-chain application the application will be compatible with the previous standard as long as one allows the field "from" to be undefined.

PSP for Name Service on Polkadot

We need to create a community standard for Name Service on Polkadot.

Some existing work:

• https://github.com/pnsproject
• paritytech/substrate#11052
• paritytech/substrate#7197

Primary Goals:

• allow DOT holders to register *.dot names which can be used to quickly look up their Polkadot Address
• have a single source of truth for these names, which helps prevent attack vectors and keeps users safe
• simple, easy, and cheap registrations for end users
• a smart way to backfill domains for existing users, trying to ensure that active or well known polkadot users (or even system accounts) get priority to register domains