Path to GDA in Protocol EVM v1

[hellwolf]

Overview

We will be pushing out the long waited 1-to-N flow feature to Protocol EVM v1.

The purpose of the 1-to-N flow feature is to

1. significantly increase the design space of "Super Apps", allowing ZILMM such as Aqueduct to go to production;
2. and deprecate IDA y replacing it with a all-in-one GDA for 1-to-N money primitives.

Technical Checklist

• New /solidity-semantic-money/ library.
• Create /GeneralDistributionAgreement.sol/:
  1. Built with new concepts: Pool, Member, Distributor, Admin, ...
     • Pool addressing scheme: We may decouple pool from distributor address.
     • What about agreement callbacks?
       a) callback to the pool distributor? a member approved a subscription,
       b) callback to a pool member? units changed for the member.
     • Buffer based solvency based on distribution flow rate.
       • No app credit needed. Actually we need app credit.
  2. Integrate with existing ERC20x NFTs: InflowNFT (for all subscribed pool members), OutflowNFT (for distributors).
  3. Create new ERC20x NFTs: PoolNFT, PoolMembershipNFT, PoolAdminNFT, ??...
  4. PoolUnits ERC20 for each pool.
• Sentinel support of GDA distribution flows.
• Subgraph entities for GDA.
• Add GDA support to SuperTokenLib.
• Add GDA support to SDKs.
• Add GDA support to metadata.

Token API Draft Proposal

TODO... (tentatively close to distribute/distributeFlow/etc.)

Technical Notes

Precision Workaround: Request vs. Actual distribution/flowDistribution Value

• Does this solution make correct accounting in the application difficult?

  • To make developers' life easier, in the token implementation, a default adjustment mechanism could be considered, an example:

    a	b1	b2	b units	flow rate	event
    0	0	0	1	0	1 unit to b1
    0	0	0	1	100	Flow2 100
    -100	100	0	3	99	2 unit to b2, auto flow rate adjustment happened
    -199	133	66	3	198	Flow2 200, auto flow rate adjustment again
    -397	199	198	5	195	3 unit to b1, auto adjustments…
    -592	316	276	5	195

• (Opinionated) Build 9 decimals of unit into the protocols.

  • But what about Bitcoins: "9 decimals may be too limiting. E.g. a flowrate of 10$/month in WBTC would already be truncated to 0 with just 1 unit."

Check if we could make the "inactiveAgreements" bitmask work correctly.

1. See _inactiveAgreementBitmap:

   protocol-monorepo/packages/ethereum-contracts/contracts/superfluid/SuperfluidToken.sol

   Line 31 in 6220f66

   mapping(address => uint256) internal _inactiveAgreementBitmap;

2. We may introduce a agreementActivenessMask to control meaning of the `_inactiveAgreementBitmap
3. This can be quite complex for managing backward compatibility.

• Or disable GDA by default as a shortcut.

[mikeghen]

This sounds good to me, I like to see the development of the new concepts.

In/outflow NFTs sounds useful, additional state tracking through IERC721 methods is helpful (as opposed to cfa/ida contract methods). It's far easier as a solidity developer to check presence of NFTs and read its attributes. This way you read only the attributes you need. The current model the calls to get pool information return several values, some that aren't needed.

[hellwolf]

Thanks for the feedback!

[hellwolf]

App credit might be needed after all, since without it Aqueduct contract would require buffer reserve proportional to its volumes.

[hellwolf]

• Pool Data Design
  • admin role
  • distributor role
  • index's data:

    total_units: 128b
    p.settled_at: 32b
    p.flow_frate: 96b
    ====
    (optimization may apply) p.settled_value: 256b
    

  • members' data:

    1 WORD for slotsbitmap entry
    ====
    p.settled_value: 256b (per unit settled value, make shiba inu great again)
    ====
    owned_units: 128b
    p.settled_at: 32b
    p.flow_frate: 96b (per unit flow rate)
    ====
    (optimization may apply) settled_value: 256b
    

• Next Steps:
  • Prototype ToySuperToken.sol:
    • function claim() // to validate that sotring one total_units is sufficient
    • multi-distributors

[hellwolf]

Actually it's not possible not to store the "unconnected units" separately. so I will have to readjust the storage layout.

[hellwolf]

It's happening!