Discussion for OSWG-1 Polkadot Token Standard

[xlc]

Please allow me to create this for discussions of OSWG-1 Polkadot Token Standard

https://github.com/paritytech/substrate-open-working-groups/blob/main/SOWG/1-polkadot-token-standard.md

[xlc]

RPC methods:

I will prefer to avoid custom RPC methods as much as possible.

1. Custom RPC support on light client is limited.
2. It is hard (if not impossible) to implement custom RPC with subscription support. Therefore polling is required to monitor for balances changes.

[jak-pan]

This is true, most of the functions described in the custom rpc section however could be substituted if there is a standardized pallet that everybody uses to query storage. (i.e. X-chain balances and asset registry)

[xlc]

Extrinsics

https://github.com/w3f/PSPs/blob/master/PSPs/drafts/psp-3.md proposed a better way to describe the extrinsic so each project don't need to use the exact same method signature.

[jak-pan]

This is cool in, but this would probably not work (it will be hard to implement safely) in cross-chain environment. We need dumbed down representation of tokens when they exit their source chain first. If we are going to encode all of the tokens logic and update it so that it will work its original magic on all the other chains this is a much bigger effort and I doubt that we can have something working in time for launch of kusama.

[xlc]

@pserg1

Each wallet/exchange would still need to come up with custom integrations

No exactly sure what's the issue. We should obviously provide reference implementation and everyone can just code against the SDK or follow the spec and do their job.

Sidecar is a tool to transfer Substrate RPC into simple RESTful like HTTP calls so integration project (e.g. exchanges) does not need to understand/implement SCALE codec or any specifics but still able to interact with the chain.

Also, I don't currently see how PSP-3 will rule out the ERC-20 tokens support for projects like Moonbeam, Snowfork and "free" balances like Equilibrium?

Quote from PSP3 "This limitation will be lift on later version, by allowing execute a WASM code in a sandbox to process the storage."

So each project can just provide a Wasm that calculates free balances from whatever storage values. It will take some work, but I don't see any hard obstacles.

---

@jak-pan

Not exactly sure what do you mean. PSP3 have nothing to do with cross-chain. It just describe how to read/write assets. Cross-chain tokens are just another asset in the destination chain. The cross-chain BTC on Acala won't be the same cross-chain BTC on Moonbeam.

I am only talking about extrinsic to do in-chain transfer and cross-chain transfer extrinsic will be a bit different (but I can't image it will be a big difference).

[pserg1]

@pserg1

Each wallet/exchange would still need to come up with custom integrations

No exactly sure what's the issue. We should obviously provide reference implementation and everyone can just code against the SDK or follow the spec and do their job.

Sidecar is a tool to transfer Substrate RPC into simple RESTful like HTTP calls so integration project (e.g. exchanges) does not need to understand/implement SCALE codec or any specifics but still able to interact with the chain.

Also, I don't currently see how PSP-3 will rule out the ERC-20 tokens support for projects like Moonbeam, Snowfork and "free" balances like Equilibrium?

Quote from PSP3 "This limitation will be lift on later version, by allowing execute a WASM code in a sandbox to process the storage."

So each project can just provide a Wasm that calculates free balances from whatever storage values. It will take some work, but I don't see any hard obstacles.

@jak-pan

Not exactly sure what do you mean. PSP3 have nothing to do with cross-chain. It just describe how to read/write assets. Cross-chain tokens are just another asset in the destination chain. The cross-chain BTC on Acala won't be the same cross-chain BTC on Moonbeam.

I am only talking about extrinsic to do in-chain transfer and cross-chain transfer extrinsic will be a bit different (but I can't image it will be a big difference).

Thank you for the input, @xlc
We're in talks with several exchanges currently, so will ask for their input/thoughts on integration as well, basically we have two approaches:

1. PSP-3 and javascript SDK
2. Custom RPCs

I will share more details as we gather them, we've also scheduled a call with Moonbeam early next year to better understand their ERC-20 requirements. I will amend the information here. Meanwhile. Let me wish you a Merry Christmas (if relevant, of course) and happy holiday season! I will be back here next year starting around 5 jan.

[crystalin]

Whether we go with Custom RPC or Substrate RPC, we will need it configurable to match the different assets. You can't come up with a custom RPC supporting all the possible cases. For Moonbeam, we already published our parachain types so using the substrate RPC doesn't seem a bad idea for our main token.
However supporting user-generated assets (ERC20, ERC1155...) will require the logic to be embedded in the SDK. Using a WASM execution to retrieve the storage key could be a solution but is not a convenient one.

What would be great is to describe some precise use-cases where we could compare the pros/cons of each solution.

[xlc]

EVM based tokens are tricky to support, especially for the one with rebase mechanism that requires some EVM code execution to calculate the balance amount...

I think the next step is we should just write down our requirements and wishlist and see if we can figure out something together.

[gregzaitsev]

Hi! Is there a document with token properties for each network? For example, Unique tokens have following properties:

Common properties:
  owner,
  collection_id

NFT: 
  token_id,
  mutable_metadata,
  immutable_metadata

Fungible (ERC-20):
  value  

ReFungible:
  token_id,
  mutable_metadata,
  immutable_metadata,
  value  

[gregzaitsev]

I think it is needed for designing minting methods

[jalex206]

Hi- we are reviewing the standards proposal in anticipation of adding support via OpenZeppelin Contracts (including potential ink! support). One question: has it been discussed/considered to provide a mechanism to allow a third party to transfer on behalf of the token holder, as with approve in ERC20? Although approve has issues, this mechanism is important on ethereum.

[xlc]

Substrate pallets generally doesn't need approve so I don't think it should be in the core part of the standard. It could be an optional addition.

But approve is just not a good design anyway, we should just allow people to call a contract and send tokens along with the call, instead of the awkward approve/transferFrom pair of calls.

[crystalin]

In the case of user-generated assets/tokens, this case might still be relevant.

[BenWhiteJam]

Please allow me to create this for discussions of OSWG-1 Polkadot Token Standard

https://github.com/paritytech/substrate-open-working-groups/blob/main/1-polkadot-token-standard.md

@xlc could you update the link? Thanks!
https://github.com/paritytech/substrate-open-working-groups/blob/main/SOWG/1-polkadot-token-standard.md

[xlc]

Done