ACs:

• Agreement.realtimeBalanceOf should return margin amount.
• SuperToken should reserve margin sums of each account as not usable amount by the user, until the agreement ends.
• app framework should implement deposit allowance feature

Spec:

function realtimeBalanceOf(
         address account,
         uint256 timestamp
     )
         external
         virtual
         view
         returns (int256 balance, int256 deposit);

• Insolvent account: balance < 0
• Critical account: balance < - margin

We will start to use chi token for upfront fee collections.
We need to have minter code and we need saver code.

ACs:

• Pack Chi minter saver code in FeeHelper library and test it.
• Test it in FlowAgreement.

P.S.:

Saver code could be copied from https://github.com/emilianobonassi/gas-saver/blob/master/ChiGasSaver.sol

Check if NatSpec integration is properly incorporated.

ACs:

• NatSpec shipped with json ABIs.
• UIs showing NatSpec enabled transaction description properly.

Acceptance criteria

• FlowAgreement can creates a new flow, with FLOW_PER_SECOND type of flowRate.
• FlowAgreement can calculate realtime balance of a account.
• SuperToken as ERC20 token, with realtime balance.
• Implement all FlowAgreement functions.
• All test cases.

Specifications

FlowAgreement functions

state update functions:

• createFlow (token, sender, receiver, flowRate)
• updateFlow (token, sender, receiver, newFlowRate)
• deleteFlow (token, sender, receiver) should be equivalent to updateFlow with newFlowRate = 0

view functions:

• getFlowRate (token, sender, receiver)
• getTotalInflowRate (token, account)
• getTotalOutflowRate (token, account)

Test cases

• Create a new flow (test createFlow function)
  • create user1 -> user2 a new flow
  • verify realtime balances
• Create additional flow (test createFlow function for multiple flows)
  • create user1 -> user2 a new flow
  • create user3 -> user2 a new flow
  • verify realtime balances
• Update an existing flow (test updateFlow function)
  • create user1 -> user2 a new flow
  • create user3 -> user2 a new flow
  • update user3 -> user2 with new flow rate
  • verify realtime balances
• Delete a flow (test deleteFlow function for multiple flows)
  • create user1 -> user2 a new flow
  • create user3 -> user2 a new flow
  • delete user3 -> user2 flow
  • verify realtime balances

ACs:

• If the account has less than X-time amount of liquidity, any agent could call the FlowAgreement.deleteFlow
• FlowAgreement.deleteFlow should allow agent to close if the sender account is in insolvent state. (Currently it only allows sender or recipient). This is temporary until liquidation permission system is setup.

Spec:

FlowAgreement.deleteFlow implementation:

(1) if not sender nor receiver,
(2) check if it allows liquidation: this will check ISuperToken.isAccountInsolvent(sender) or ISuperToken.isAccountInsolvent(receiver)
(3) if (2) is true, then allowing the msg.sender to close the agreement for sender or receiver
(4) distribute the margin as reward

SuperToken.isAccountInsolvent(account) implementation:

• when account.realtimeBalanceOf(block.timestamp).balance < 0
• margin is to be implemented in #24

To further save some gas, we may replace the current bytes based agreement storage with field based instead.

some of the files have too long lines, we will enable max line 100 or 120.

Follow the "one agreement one data" principle.

Why can't we simply query the current block.timestamp?

ACs:

• Implement CIA agreement according to the notion.so spec
• framework requirements:
  • callback
• tests

Incorporate discussion from the protocol workshop: https://app.diagrams.net/?state=%7B%22folderId%22:%2218OZ-0C2khzIWkuSYnJWyxcqoqR2oQH4h%22,%22action%22:%22create%22,%22userId%22:%22104853936918337007700%22%7D#G1HtfzpS1sKgB5ggFG-mHjCKuYpLKKZlED

• coveralls
• enforce coverage requirement

• without upgradability yet.
• create super token provided with underlying token address.
• governance interface and dummy government contract for testing purpose.

Synopsis: a non-upgradable simple contract that upgrades the token for the approving user and transfer all back to the user (for free).

Target Release: v0.2

Spec

TBD.

ACs:

TBD.

Miao will take this on and organize a bit the test cases.

The spec is in the notion doc.

Multiple test tokens have been created and super token wrapper have also been created for them.

They can be resolved to :

• tokens.fUSDC
• tokens.fDAI
• tokens.fUSDT
• tokens.fTUSD

And their wrapper could be fetched by using:

const registryAddress = await testResolver.get("SuperfluidRegistry.master");
const registry = await SuperfluidRegistry.at(registryAddress);
const tokenInfo = await TokenInfo.at(tokenAddress);
const superTokenWrapper = Superfluid.getERC20Wrapper(registry, tokenInfo);
const superToken = await SuperToken.at(superTokenWrapper.address)

Synopsis: Currently agreement data is stored as bytes[], and using solidity mapping for addressing, instead we could use fixed sized bytes32[] and direct addressing in assembly to not save the "length" field of the dynamic bytes array.

Target release: v0.1

Spec

Changes required in agreements:

• all agreement data function require length as input
• use getAgreementStateSlot/updateAgreementStateSlot and provide data length
• explicit setAgreementInactive call to deactivate agreement from user account.

ACs

• agreements updated
• test passes
• gas usage reduced

The opposite of upgrading token to super token is downgrading, it is important that one can downgrade and see the underlying token again. Checks must be in place to assure the solvency, and one cannot downgrade more than he owns.

Specifications

SuperToken

• function downgrade(uint256 amount)

Test Cases

• All test cases should end up with downgrading existing super tokens, and token balances should be tested according to the spec.
  • one can settle and downgrade/withdraw up to static balance + realtime balance
  • one cannot settle and withdraw more than static balance + realtime balance

Rationale

With typed signature specified in ERC-712, batch operations could be signed in a human readable way in supported wallet interface.

It provides a great UX improvement, as an alternative to the radspec approach.

Target release: v0.2

Spec

• TODO

ACs

• TODO

Notes

• function selector could be part of the typed signature, looking like "foobar(address,uint256)". The function name part is the human readable part, however the parameter list unfortunately cannot be ommitted.
• the signed signature could be relayed as a meta tx, and be broadcasted by the user directly.
• should review delegatable framework for composable 712 signatures.

• flowRate uint96
• timetstamp uint32
• remove sender/receiver from storing, and make agreementId dynamic bytes instead

Synopsis: By enforcing ERC-777, a super token cannot be sent directly to a contract, instead the contract must implement the IERC777Recipient interface. By doing so the contract could implement additional logic reacting on super token received event.

Target release: v0.1

Specs

ERC-777

ACs:

TBD

if the activeAgreent Array is too big, DoS could be a security issue.

ACs:

• finalized v1 interface
• core logic
• framework requirements:
  • callback
  • deposit
• tests

In relation to #43, one solution is to always set super token decimals to 18 decimals.

As a consequence:

• Downgrade/Upgrade needs to convert decimals between the underlying and super tokens
• For 112 bits flow rate, the maximum flow rate for 18 decimals underlying is 519229685853482.75 / sec

ACs:

• Supertoken downgrade/upgrade to convert decimals
• Re-deploy all super token wrappers with fixed 18 decimals

Problem: low decimals of underlying tokens(for example using USDC at 6 decimals, ~2.5 USDC/mo granularity)

Synopsis: The agreement should be implemented in such way that when bond system is put in place, its code needs not to be updated.

Spec

• The agreement can check if the account is solvent, and decide if the agreement can be "liquidated".
• The agreement must not transfer the deposit directly, but instruct the release of the deposit to the reward address.
• The superfluid framework transfer the deposit to the rightful owner, be it the liquidator or the liquidation agent or the bond holder, depending on the system in place.

ACs

• code reviewed
• start with free agent system, liquidation agent takes it all
• tested

Having two state variables for the balance is a waste. We could consider to eliminate ERC20Base all together to have an single version of SuperToken that does it efficiently.

ACs:

• add deleteFlow function with sender address param and msg.sender is either sender or receiver.
• test case

ACs:

• Add a technical notes under the "Constant Flow Agreement" section.

A leading underscore should indicate it is a private/internal field of the contract, using it in other cases loses its purpose.

Add token upgrade/downgrade operation to Superfluid.batchCall.

check impl of https://github.com/Uniswap/uniswap-v2-core/blob/816075049f811f1b061bca81d5d040b96f4c07eb/contracts/UniswapV2Factory.sol#L23

Include agreementClass and version.

Tips for the agent:

1. Try to use introspect to detect what type of agreement it is.
2. If introspection failed (try/catch) assume it uses the current constant flow agreement interface.
3. If introspection succeed, and agent doesn't know understand the type of agreement, crash/assert.
4. Use the constant flow agreement abi from the installed npm package.

Synopsis: Due to the use of call proxy, batch call, etc, it is not a simple web3 call to interact with the superfluid frameworks, a minimalistic js-sdk is shipped along with the project to simplify the usages. Framework class is the main class used for that purpose.

Specs

• initialize
  • token list
• token registry
  • getERC20Wrapper
  • createERC20Wrapper
• sf.cfa
  • createFlow
  • updateFlow
  • deleteFlow
  • getFlow
  • getNetFlow
  • listFlows

Deferring these to new tickets:

- [ ] sf.ida
  - [ ] createIndex
  - [ ] updateIndex/distribute
  - [ ] approveSubcription
  - [ ] updateSubscription
  - [ ] listSubscription
  - [ ] deleteSubscription
- [ ] sf.callAppAction
- [ ] sf.batchCall

Related to #43

Rationale:

• Underlying tokens could have very different decimals
• To avoid granularity problem due to low decimals of underlying tokens(for example using USDC at 6 decimals, ~2.5 USDC/mo granularity), flow rate could be with an underlying token independent unit: "1.0 underlying token"
• Further more, to squeeze in/out flow rates in one word, UQ56x56 could be utilized. Which could encode up to 72057594037927936 / sec

--

Alright, we are not doing this. But I will write it down as a archived issue.

We are opting for 18 decimals super tokens.

Add TransferFrom operation to Superfluid.batchCall.

• v0 branch
• v0 CI
• v0 CD - update ContractName.v0 in resolvers