ERC20x

[hellwolf]

ERC20x

ERC20x is a set of ERC20 extensions amalgamating the idea of Superfluid Money with the principle of tokenize all data using ERC721.

What You Will Get

• Accessing novel payment primitives of Superfluid Money through token-centric APIs (e.g. token.createFlow).
• Existential NFTs for non-fungible super token data (Tokenizing All Data, TAD):
  • DAIxCOF (Constant Outgoing Flow of DAIx)
  • DAIxCIF (Constant Incoming Flow of DAIx)
  • DAIxPUB (Publishment of DAIx Proportional Distribution Index)
  • DAIxSUB (Subscriptions of DAIx Proportional Distribution Index)
  • Note 1: xCOFs and xCIFs are not restricted to 1to1 relations (universal indexes), in lieu of the creation of 1toN flows xCOFs and xCIFs should be shared by those multi-party flows as such.
  • Note 2: One should think of NFTs as reinterpretations of the token-centric APIs for NFT eco-system integrations.
  • Note 3: NFT approvals could be handy for an alternative ACL API reinterpretation.
• Accounting Information Recoverability (AIR):
  • (mandatory) accurate cash accounting must be possible off-chain via on-chain LOGs.
  • (optional) on-chain accounting is amicable but perhaps too costly.
• EIPs!
  • They will come as side products of the first draft implementation in Superfluid EVM v1!
  • Each payment primitive must have its own EIP with its set of token-centric APIs, and their reinterpretations in existential NFTs, along with:
    • correctness defined mainly through law of Conservation of Value (LCV),
    • inclusion of AIR principle.

What Is Superfluid Money

Superfluid Money is a programmable composable semantically rich internet money that can stream value at scale.

Specifically:

• Internet Money: production live for more than a year on 6 EVM chains, with more than 100M$ streamed to date.
• Semantically Rich: novel payment primitives including flow (constant value transfer measured per second), distribution index (e.g. * paying dividend in one transaction, or in flows), etc. Read yellowpaper here.
• Composable: liquidity settled continuously in time on blockchain.
• Programmable: smart contracts based development framework with infinite design space, allowing novel applications such as DCA investment every second.

Goals of ERC20x

External

• Token-centric APIs is love.
• Popularize the principle of Tokenize All Data (TAD).
• Super Token needs EIPs.
• Promote more super token ecosystem building (etherscan, metamask, portfolio scanner, ...).

Internal

• Deprecating callAgreement call proxy.

Observation

• Accounting information should be fully recoverable off-chain (so at least as events, if not as on-chain query-able data).
• Especially currently buffer based solvency information is not retrievable directly off-chain.
• ERC20x should be agnostic to how solvency is designed.
• All data can be tokenized (fungible form of data - ERC20, non-fungible information interpreted as ERC721).
• How to build Super app framework on top of ERC20x without having to leak its design in the ERC20x.

Design Principles

• Law of Conservation of Value (LCV)
• Accounting Information Recoverability (AIR)
• Tokenize All Data (TAD)

Meeting Minutes

• Protocol Public Forum 2022-10-05 - ERC20x

[hellwolf]

Please read the updated "What You Will Get" section and heading section!

[hellwolf]

ERC20x NFT Crystal

[hellwolf]

The Crystal Math for Single-Word Mapped TokenId's

[0xdavinchee]

Follow up on a comment last week regarding many NFTs being minted as a result of this new feature and the fairly large increase in gas costs-one easy work around is to make this feature opt-in, we do not mint NFTs for users by default, you must explicitly toggle this on/off at the account level in the protocol.

Caveat note to self: Someone can toggle on, create flow/index/subscription to mint NFT, toggle off and delete flow and still have the NFT-this should be a powerless NFT and if they toggle on, create flow/index/subscription with same id should not be broken by this.

[0xdavinchee]

Some other comments, notes and considerations following demo day presentation:

• are there any other NFT events that can be emitted during update of flow/subscription units so that OpenSea or other integrations can be updated (metadata updated events)
• important to specify: where are the NFT resources are hosted and how this is represented, generate a URL to IPFS/Arweave based on metadata, how we want to generate visually
• important to emphasize: NFT will have built to inflow transferability (can redirect and transfer to defi protocol), inflow streams, that is
• IF approval/access control is set at the NFT level, we should not have the user interact with the protocol directly to set ACL permissions, approval set at the NFT level is indication of ACL approval
• Bounce ideas w/ integration partners, developers:
  • Need to make sure we don’t prevent any use cases-approach: feedback use case CAN be implemented with the protocol. Design surface should be large enough to be able to work with the use case. If we cannot, we have to think about how we can make the design surface broader or we just have to tell them it’s not possible in certain cases.
• Tricky thing: gas costs increase, for many use cases, this won’t be exactly what is needed, will have to create super app, which creates nft, leads to proliferation of nft’s, generic SF NFT and contract specific NFT and it becomes a bit weird
• What use cases cannot be built? Simplest example, if I want to customize metadata, I can’t, if I want my brand on it-can use userData

[kobuta23]

I like the idea of being able to turn it off. This could be a protocol setting and then a toggle.
So on Polygon it's default on, and on mainnet it's default off.

Not sure where this toggle would sit though, and there could be endless "granularity" discussions about it.

For example. What if Alice has toggle on, and Bob has toggle off? What happens when Alice streams to Bob? And what about when Bob streams to Alice?

IMO most of these convos will be around apps (who can actually issue NFTs). Users can't.
So I'd give SuperApps some sort of overriding powers, and then just assume other users "go with the flow"

[d10r]

I think the option to turn it off would violate the AIR principle.
If we manage to implement without storing extra data (depends e.g. on the question if we need to return the current number in balanceOf for the NFTs), this should be a non-issue with basically just the extra event remaining.

[0xdavinchee]

From discussion with Didi:

• is it possible to retain the tokenId across transfers (a counter)
  • yes, but it will increase the gas costs as another mapping from tokenId to flowId will need to be created and updated quite frequently.
  • conclusion: best to go with the cheaper option for now for v1 and
• there might be a problem with minting and burning in transfer, must consider the implications of how this interacts with existing NFT infrastructure out there
  • Do some preliminary testing with relevant NFT wallets to see if doing this plays nicely
  • Our theory to be tested: as long as we emit a transfer event first with from, to, tokenId, then burn this token and mint the new one with the new id and the ownerOf field is correct, it should play nicely
• is balanceOf supported by existing NFT infrastructure?
  • we are currently using an extra mapping in storage to track this and maybe we don't want to if non of the tooling uses this field
  • maybe we can set it to 0 or 1 depending on existence of any agreement
  • if we want to store it, maybe we can store it without using a whole word

Indexes

• on creation of an index, we could use something like proxy clone pattern to create a proxy contract with its own storage
  • this may make it easier to interface with IDA
  • might allow something like transferring a stream receiver NFT to index makes it become an FDA
  • the contract should be an ERC20 interface where the balance represents units
  • maybe we create some sort of wrapper which makes it easy to convert an ERC20 to an index
  • we must consider how this plays with FDA when it is released, that is, how this contract is implemented

[0xdavinchee]

List of integrations/wallets to do an MVP contract test with on mainnet (most expensive, but for broadest testing):

• OpenSea API
• Twitter API
• Instagram API
• Rainbow (no custom additions by token address)
• Metamask mobile
• Zapper mobile app
• Zerion mobile app

We would just need to deploy two minimal NFT contracts (MVPOutflow, MVPInflow) and want to test:

• does Mint and Burn behave properly
• what happens with not following EIP-721 standard 100% w/ transfer function also emitting Burn and Mint event following Transfer event
• what happens when MetadataUpdated is emitted

[0xdavinchee]

Comment from Fran:
Have some sort of hook only available in SuperApps which could somehow alter the NFT issuance.
This is mainly to avoid situations where a SuperApp needs to issue a specific kind of NFT, which would lead to a double NFT being needed.
It’s not the end of the world to have double NFTs, and we may find the complexity of what I’m suggesting isn’t worth it, but still worth looking into.
The simplest implementation could be that a SuperApp can send a call to the _host (in a callback) which would set custom metadata for the required tokenId.

[d10r]

Note 1: xCOFs and xCIFs are not restricted to 1to1 relations (universal indexes), in lieu of the creation of 1toN flows xCOFs and xCIFs should be shared by those multi-party flows as such.

Can/shall we make them transferable too?
Thinking about it, imo it could be possible, with interesting semantics:

• all receivers of an 1:n flow are allowed to invoke transferFrom on the related xCIF.
• this causes the index units of the old receiver to be transferred (ERC20.transfer() on the index) to the new receiver.
• A 721 Transfer event with from being the old receiver and to being the new receiver could be emitted - would that break any tools/wallets though if from doesn't match the owner address at the time?

Also, regarding AIR:
We can't provide that via the 721 events alone as the Transfer event of the shared xCIFs can't enumerate all flow receivers.
However if indexes are represented by dedicated contracts, AIR should be possible by looking at 721 and 20 events: if a xCIF is minted to an index contract, observing ERC20 Transfer events on that contract should allow to reconstruct all balances at all times.

Caveat: if a flow goes to an ERC20 contract which isn't an index (no hooks into SF), this could result in bogus data.
I think we should have interface detection for index contracts, e.g. via EIP-165.
The potential use of existing ERC20s as index could be achieved via transparent glue contracts.

[d10r]

update after discussing with Vincent:
We can (and probably should) have xCIF tokens per subscriber for 1:n flows, but only without Transfer event (not scalable) and only if the xCIFs are implemented stateless. Could allow for deferred (permissionless?) event triggering, but maybe not a good idea bcs of timestamp mismatch and indeterminism. This per-subscriber tokens could be additional to the shared one.
How useful would they be without event? Not shown in wallets unless manually added. The API e.g. for transferring would probably be more natural than when invoked on the shared NFT.
We should probably make a few assumptions/definitions about AIR - e.g. I'd assume that AIR is possible based on events alone (+ medium-complex calculation logic).

[kasparkallas]

Rename "COF" & "CIF" to "OCF" ("Ongoing Constant Flow") & "ICF" ("Incoming Constant Flow") to be more uniform looking with CFA?

[hellwolf]

Unfortunately, ICF and OCF is not pronounceable :)

[d10r]

about composability programmability

The current SF implementation uses a mix of hooks which can be delegatable or non-delegatable and mandatory or optional.
Currently all of them are sync (atomic).

Instant 1:1 transfers use optional, delegatable hooks:

• ERC20.transfer() does not call any hooks
• ERC777.send() does call delegatable hooks

Constant 1:1 flows use mandatory, non-delegatable hooks:

• create/update/deleteFlow does call non-delegatable hooks

Instant 1:n transfers (aka Instant Distributions) use mandatory, non-delegatable hooks too
approve/update/revoke/deleteSubscription and claim do call non-delegatable hooks

Mechanisms for setting up hooks:

Instant 1:1 transfers use the ERC777 interface:
implement ERC777TokensSender.tokensToSend/ERC777TokensRecipient.tokensReceived and register the implementing contract with ERC1820.setInterfaceImplementer

Constant 1:1 flows and Instant 1:n transfers use the SuperApp interface:
implement ISuperApp.before/afterAgreementCreated/Updated/Deleted in the receiver contract and register (whitelist) it with ISuperfluid.registerAppWithKey/ByFactory.

Observations

• The mechanism for Instant 1:1 transfers is very different from the mechanism for Instant 1:n transfers.
• It's not possible to "skip" hooks for Instant 1:n transfers and Constant 1:n flows. This has implications on gas costs and their predictability, reentrancy, consistency guarantees.
• The relationship/mapping between methods related to Instant 1:n transfer and hooks to the SuperApp interface isn't very intuitive.
• Only hooks for Instant 1:1 transfers can be set up in permissionlessly.
• Optional hooks limit the attack surface and could thus facilitate the transition to permissionless hook set up for all operations. To be investigated if that would break any existing applications.
• Delegatable hooks are on the wishlist. The ERC777 mechanism (via ERC1820) is deemed a bit heavyweight though - we may explore simpler alternatives and adopt one for all operations.
• We may want to support async hooks programmability in the future.

[d10r]

update after discussing this:

• Only hooks for Instant 1:1 transfers shall be and remain optional
• All hooks shall eventually be permissionless
• We define "hook" to mean mechanisms for sync programmability

[d10r]

see #1261

[hellwolf]

Going forward, let's correct terminologies (it was a bit confused before):

1. Use of compositionality is preferred over composability in more formal context.
2. compositionality /= programmability:
   • compositionality in the context of superfluid money is about the ability to use the monetary value the moment it's received.
   • programmability is about being able to trigger actions conditionally by programming, often (but not restricted to) through hooks.