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.
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.
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).
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.