How should the Conditional Tokens Framework deal with ERC1155s, ERC20s, and compatibility with the rest of the ecosystem?

[auryn_macmillan]

In order to allow GnosisDAO to provide more liquidity to GIP related markets (along with further proliferating the conditional investment and governance use-case for conditional tokens / prediction markets), we need to create, or use an existing, AMM that supports trading between positions representing the same outcome with different collateral; yesDai <> yesGNO, for example.

This could be achieved with existing AMMs, like Uniswap or Balancer, but they lack ERC1155 support. @alanlu’s ERC1155-ECR20 wrapper contract provides a solution to this, but introduces some issues as well (increased gas cost and poorly supported metadata).

As such, I see three potential paths forwards, each with pros and cons.

1. ERC1155 maxi: continue using ERC1155 tokens and build out new AMM contracts (along with accompanying tooling) to facilitate trading between positions representing the same outcome with different collateral: yesDai <> yesGNO.
   Using this approach, we keep the existing benefits (lower gas costs) and challenges (poor adoption) of the ERC1155 standard.
   Perhaps there is also an option to modify some of the existing ERC20 contracts and tooling to be compatible with ERC1155.

2. Hybrid: continue using ERC1155 under the hood and where it’s already been implemented (the existing market makers, Omen, etc), but use wrapped ERC20 tokens to interact with other platforms. This approach gets the benefit of ERC1155 for those using it and the benefit of compatibility with the rest of the ecosystem, at the cost of some additional gas and UX hiccups for those looking to move between interfaces/apps using different token standards.
   There would also need to be a choice about how to deliver metadata to interfaces. The current wrapper uses the same metadata for all tokens (it is intended as a generic ERC1155 wrapper), this is problematic as different wrapped conditional tokens render with the same metadata in most interfaces, making them indistinguishable from one and other. This could be dealt with in two ways: (a) create a new wrapper that includes metadata from the conditional token (costs dev time but makes wrapped tokens more universally compatible), or (b) maintain and propagate a tokenlist(costs admin time to maintain manually or dev time to automate, costs BD time to propagate, will not be universally compatible / there will always be some interfaces that do not render the metadata).

3. ERC20 maxi: accept that ERC20 is dominant and that ERC1155 is unlikely to be as widely used (in the near future), even if it is a better token standard for this (and most) use-case(es), and build a V2 of the conditional tokens framework that uses ERC20 tokens in place of ERC1155. At the cost of a significant amount of dev time and increased gas costs, this would allow conditional tokens to more seamlessly interact with the rest of the ecosystem.

One good indicator on the way this decision should go is how willing we (Gnosis), along with other organisations using conditional tokens (the DxDAO, for example), are to support the ERC1155 token standard in our other products. If we are unwilling/unable to support ERC1155 tokens natively in our own ecosystem (Gnosis Protocol, Gnosis Safe, and indeed as collateral in the Conditional Tokens Framework), then we perhaps we should abandon ERC1155 for conditional tokens and go with option 2 or 3.

[corkus]

@auryn_macmillan could you go more into details what are the advantages of using ERC1155? Is it only gas costs?

[auryn_macmillan]

There are several gas, efficiency, and security benefits:

1. Creating new tokens does not require deployment of new contracts with ERC1155, it does with ERC20.
2. Transfers are cheaper.
3. Transfers can be done in batches of tokens, making them cheaper again.
4. Transfers a safer, as you can’t send to an address that is not an EOA or a contract specifically designed to interact with ERC1155.
5. setApprovalForAll() approves all tokens in a specific multisig contract, so you don’t need to call approve() for each token you want to interact with.

@alanlu may know of some other benefits.

[sky]

This is a critical topic and will lead to very interesting discussion.

From my point of view, I will keep things super simple. At this point in time:

1. ERC20s optimize for transparency, freedom, creation, and interoperability
   (a simple fact like not being able to see or value your conditional tokens in a wallet or on Etherscan is a huge drawback)

2. The current ERC1155 conditional token framework seems to operate ok on its own but is missing out on so much because of the lack of connection to the rest of the DeFi ecosystem.
   (you could compare it to something like Uniswap LP tokens. It would be a huge disadvantage if these were not ERC20 tokens.)

3. Higher costs associated with ERC20 tokens may matter less and less as L2 solutions emerge.

4. Wrapping and unwrapping ERC1155s into and out of ERC20 will likely lead to many other UX issues as we move forward.

5. The gas, efficiency, and security benefits of ERC1155s seem very good

Is it possible to create a new standard that does the best of both? It does everything an ERC20 can do with the added benefits of ERC1155?

I can’t imagine that the same old ERC20 standard is what we will all be using in a few years. But any new standard would have to be backwards compatible.

[GraemeB]

The Conditional Token Standard working with the ERC1155 has made integration or co-operation with other protocols very difficult. It’s essentially a non-starter when speaking to a protocol that doesn’t use the 1155 standard and they account for the majority. The wrapper does solve this to a degree but at the cost of GAS saving brought about by the 1155 standard (maybe not such a big problem) and the lack of metadata (a huge problem in my opinion).

The original gnosis prediction markets were ERC20s. The reason for the development of the conditional tokens was specifically to enable conditional markets for the purpose of governance via futarchy. This had been tried before by level K with the old Gnosis prediction market contracts but they ran into:

• high gas costs when minting new ERC20’s to represent a new outcome.
• strict order in which outcome tokens need to be redeemed as each outcome is represented by its own contract.

Can we have our cake and eat it too? I don’t think we could escape GAS fees, but perhaps this is a non-issue if we believe usage will move to L2. Can we have the fungibility of conditional tokens at deeper levels with ERC20s? I’d have to defer that to someone more technical expertise than I have, but for me, this is really the clincher. If yes, then I only see upsides to ERC20 approach on a layer 2. Is this the case?

[auryn_macmillan]

@sky

you could compare it to something like Uniswap LP tokens

Actually, the LP tokens on Omen are ERC20 tokens.

[auryn_macmillan]

@GraemeB

Can we have the fungibility of conditional tokens at deeper levels with ERC20s?

@alanlu would it be possible to create deterministic addresses for the ERC20 tokens in the same (a similar) way to how we create deterministic IDs for the ERC1155 tokens?

[sky]

!!!

Can we invent new token standard ERC999?! that does everything we need.

[0x7]

I would support 2, with the modification to the ERC-1155 wrapper to include market specific metadata.

I think it is too soon to give up on a new token standard, and I also think for Omen, ERC1155 does not present a huge issue. The core problem is with conditional tokens cross-dapp integration, for which the use cases are still developing.