Skip to content

General Distribution Agreement

Jump to bottom
Miao ZhiCheng edited this page Oct 3, 2023 · 19 revisions

Overview

GDA (General Distribution Agreement) generalizes the Instant Distribution Agreement by offering many-to-many constant flow distribution in addition to the one-to-many instant distribution.

GDA is implemented using the Superfluid agreement framework, however it does not currently provide #Lack-of Callback Support unlike the IDA.

Implementation Guide

Usage of Semantic Money Library (Limited Functional Programming)

TODO miao

Code Structure

The code structure of the GDA deviates from the two existing agreements in that it leverages the TokenMonad abstract contract which leverages the Semantic Money Library.

SemanticMoney.sol: This is a library that contains the low-level building blocks of the Superfluid payment primitives. That is, the data structures and the pure functions that operate on them.

TokenMonad.sol: TokenMonad is an abstract contract that contains:

  • a set of virtual getter/setter functions to be implemented by the inheriting contract:
    • _getUIndex/_setUIndex
    • _getPDPIndex/_setPDPIndex
    • _getFlowRate
    • _setFlowInfo
    • _getPoolAdjustmentFlowRate/_setPoolAdjustmentFlowRate
  • the core logic for the different types of agreement operations:
    • _doShift (instant transfer)
    • _doFlow (1-to-1 flow)
    • _doDistributeViaPool (1-to-n instant transfer)
    • _doDistributeFlowViaPool (1-to-n flow)

The core logic functions utilize the SemanticMoney library and the virtual functions to enact side effects on the state of the inheriting contract.

GeneralDistributionAgreementV1.sol: The GDA contract inherits from ISuperAgreement (similar to the CFA and the IDA) and TokenMonad. This contract can be thought of as the interface between the TokenMonad/SemanticMoney library and the existing Superfluid protocol and therefore the end-user. It is the contract that is responsible for sanitizing input data as TokenMonad/SemanticMoney offloads this to the inheriting contract. It includes the following:

  • implementation of the virtual functions in TokenMonad.sol
  • the SuperfluidPool creation function
  • callAgreement wrapper functions for the core logic functions in TokenMonad.sol and some SuperfluidPool.sol functions
  • encoding/decoding of arbitrary data to/from SuperfluidToken storage similar to the CFA and IDA

Major Design Choices

Superfluid Pool

The Superfluid Pool is a contract that is created via the GDA contract and enables the distribution of funds to N pool members. The admin of the pool can update the units of the pool members at any time and distribute to the poole members.

Happy Path Distribution

A happy path would look like:

  • Alice creates a new pool via the GDA and sets herself as the admin
  • Alice updates pool units for Bob (100 for Bob) and Carol (200 for Carol)
  • Bob decides to connect (approve subscription in the IDA) to this pool
  • Alice instantly distributes 300 POOLx tokens to the pool
  • Bob now has 100 POOLx tokens
  • Alice has 200 claimable POOLx tokens, she claims and now has 200 POOLx tokens

NOTE: The difference with a flow distribution would be that Alice would set a per second flow rate to be distributed via the pool and the recipients would receive a proportion of that flow rate based on their units.

Separation of Superfluid Pool

One of the primary differences between the GDA and the IDA is that a publisher in the IDA calls createIndex in the IDA which creates a new index that is embedded in the storage of the SuperfluidToken whereas in the GDA, an admin calls createPool to deploy a new SuperfluidPool contract. The SuperfluidPool contains a function for the pool admin to update member units and for disconnected pool members to claim any tokens which have been distributed and are unclaimed.

Many-to-many Distribution Support

A SuperfluidPool can be configured to only allow the admin of the pool to distribute (1-to-N), see the PoolConfig struct in IGeneralDistributionAgreementV1.sol. Another difference between the GDA and the IDA is that it supports many-to-many instant and flowing distributions versus only one-to-many instant distributions in the IDA.

Superfluid Pool is Token-Specific

Similar to how Indexes work in the IDA, the SuperfluidPool in the GDA is token-specific. That is, a SuperfluidPool can only distribute tokens of the same type as it was created with: createPool(ISuperfluidToken token, address admin, PoolConfig memory config).

Lack-of Cascading Superfluid Pool Support

Edge case:

  • Generally, there exist a nanny-rule that one cannot update units of pool A for another existing pool. However, one can still create some units of pool A for pool B before the pool B is created.

Solvency Mechanism

Lack-of 3P Support

Misc

Adjustment Flow

(miao)

Lack-of Callback Support

(miao)

References

Docs | Dashboard | Console | Twitter | Discord

Superfluid Protocol Wiki

Clone this wiki locally