Investigate ENS' TokenStream contract

[PaulRBerg]

ENS has a strange implementation of token streaming:

function claimableBalance() public view returns(uint256) {
      if(block.timestamp < startTime) {
          return 0;
      }
  
      uint256 end = endTime;
      if(end > block.timestamp) {
          end = block.timestamp;
      }
  
      return (end - startTime) * streamingRate - totalClaimed;
}

function claim(address recipient, uint256 amount) external onlyOwner {
      uint256 claimable = claimableBalance();
      if(amount > claimable) {
          amount = claimable;
      }
      totalClaimed += amount;
      require(token.transferFrom(tokenSender, recipient, amount), "TokenStream: Transfer failed");
      emit Claimed(recipient, amount);
}

It's an open-ended implementation, but it's a strange one. They seem to be continuously extending the end time.

Parameter values:

• startTime is January 1, 2022
• end is set to type(uint256).max
• streamingRate is 133102, i.e., ~0.13 USDC per second

I have not worked out the low-level details of how this contract plays out in practice. I am not sure what happens when the contract is not topped up - the claimableBalance value seems to keep increasing. And thus, the implementation seems to resemble LlamaPay.

References:

• https://contractreader.io/contract/mainnet/0xB1377e4f32e6746444970823D5506F98f5A04201
• https://discuss.ens.domains/t/update-on-the-ens-streams-dates-rules-and-implementation/18138/19?u=prberg

[PaulRBerg]

There was a misconception in the OP:

They seem to be continuously extending the end time.

The end time is NOT extended. end is a local variable on the stack, not a storage variable.

With that out of the way, I think I understand how the contract works now:

• Setting the end time to max uint256 means the sender will continue owing the recipient ~0.13 USDC in perpetuity
• Of course, there's no obligation on behalf of the sender to do this. It's all dependent on the ERC-20 allowance given by the sender to this contract. If the allowance is sufficiently high, the contract owner will be able to call claim and transfer tokens from the sender to the recipient.
• The contract is a bare-bones replica of LlamaPay, except that there is no bespoke debt tracking and the ERC-20 allowance is the rate-limiting factor.
• Another way to put it is that this is an onchain accounting device for keeping track of the tokens owed by the sender to the recipient.
• Yet another way to put it is that the contract acts as a Direct Debit mandate for the recipient, who is now allowed to pull tokens from the sender's account according to some pre-defined rules.

The benefit of using this smart contract over of a simple off chain balance calculator is that the recipient can pull funds as they accrue without asking for the sender to make manual payments.

[PaulRBerg]

One outstanding question is: how do Flow-like deposits compare to this?

My hunch says that Flow deposits are still needed to allow a sender to pay multiple recipients without deploying a contract for every recipient, approving each contract, managing multiple allowances, etc.

[smol-ninja]

I don't think approval based transfers are any different from Flow deposits, even worse. Imagine an address approves multiple stream contracts. This creates three issues:

1. In case of multiple recipients, withdrawals are handled on a first come first served basis. Recipients will have automate their claims by building bots or using MEV services.

2. Since the address has approved so many recipients, the sender would use this address exclusively for this purpose. He wouldn't touch it for other DeFi activities. For instance, imagine selling ETH for USDC and quickly losing those USDC to the approved streams. Thus, I believe the user will only make deposits to this address whenever necessary, making it no different from Flow deposits.

3. If there is debt and a recipient forgets to claim their funds, the sender can simply refund it, grieving the recipient. In contrast, Flow guarantees that the sender can only refund an amount that does not create further debt.

[PaulRBerg]

Thanks very much for chiming in @smol-ninja, you've fast-tracked the process of understanding the downsides of this model for me. All great points.

the sender can simply refund it, grieving the recipient

I didn't understand this part. Would you mind re-explaining, please?

The claim function is owner-controlled, and the owner is probably the recipient.

[smol-ninja]

Imagine a claimable balance of 1000 tokens (i.e. debt = 1000). The sender transfers 1000 tokens to his address for the recipient to claim (claim moves tokens from sender address to recipient address). If the recipient doesn't claim within a month, the sender can transfer the amount back, recreating the debt.

In Flow, if the debt is 1000 and the sender deposits 1000 tokens to the Flow stream, the sender cannot retrieve it because those 1000 tokens belong to the recipient. In Flow, sender can only refund the surplus amounts.

[PaulRBerg]

Oh, I see what you mean now. Thanks for explaining.

Basically, ENS's bare-bones implementation does not enforce the streaming in any way whatsoever. It's just a glorified math function.