[Phase-3][Binding] UIP-1: Development of UBI v2 with Streaming Features

UIP: 1
title: Development of UBI v2 with Streaming Features.
author: @santisiri @juanu 
status: Phase 2
created: 2021-08-18
conflicts with: None
languages: EN

Simple Summary

The ability to delegate the accrued UBI to a different address will allow pooling of UBI and increase its utility in multiple ways. This UIP will expand the features of the UBI token to include streaming capacity following the guidelines of EIP 1620 (EIP-1620: Money Streaming) and the Sablier implementation (https://github.com/sablierhq/sablier) that led to more robust and simpler code.


Today only those addresses that become verified humans on Proof of Humanity get the right to accrue UBI over time. It has been often said that some of the humans receiving UBI would like to donate it to someone else who might need it more or even stream the accrued UBI to a charitable organization. By allowing the addresses receiving UBI to delegate the streamed accrual to different addresses, these actions can be easily taken. This would increase the utility of the UBI token as well, turning into a streamable asset that can unlock new possibilities for UBI.


In order to do a secure implementation with road tested code, the UBI smart contract will be expanded implementing the ISablier interface that has been used on mainnet by the Sablier service that acts as a wrapper to stream ERC20 tokens:

 * @title ISablier
 * @author Sablier
interface ISablier {
     * @notice Emits when a stream is successfully created.
    event CreateStream(
        uint256 indexed streamId,
        address indexed sender,
        address indexed recipient,
        uint256 deposit,
        address tokenAddress,
        uint256 startTime,
        uint256 stopTime

     * @notice Emits when the recipient of a stream withdraws a portion or all their pro rata share of the stream.
    event WithdrawFromStream(uint256 indexed streamId, address indexed recipient, uint256 amount);

     * @notice Emits when a stream is successfully cancelled and tokens are transferred back on a pro rata basis.
    event CancelStream(
        uint256 indexed streamId,
        address indexed sender,
        address indexed recipient,
        uint256 senderBalance,
        uint256 recipientBalance

    function balanceOf(uint256 streamId, address who) external view returns (uint256 balance);

    function getStream(uint256 streamId)
        returns (
            address sender,
            address recipient,
            uint256 deposit,
            address token,
            uint256 startTime,
            uint256 stopTime,
            uint256 remainingBalance,
            uint256 ratePerSecond

    function createStream(address recipient, uint256 deposit, address tokenAddress, uint256 startTime, uint256 stopTime)
        returns (uint256 streamId);

    function withdrawFromStream(uint256 streamId, uint256 funds) external returns (bool);

    function cancelStream(uint256 streamId) external returns (bool);

Rather than using an external contract, these features will work natively with the UBI token and use the native streams from Proof of Humanity. Users will be able to:

  • Only Proof of Humanitty verified addresses can initiate a steam.

  • A human can stream a fraction or the entire UBI accrual to a third party address, whether it’s a verified Proof of Humanity address or not.

  • A human can create 1 or many streams, each carrying its own streamId.

  • A ubiPerSecond amount is specified when a stream is created.

  • Receiving addresses will be able to withdrawFromStream the accrued UBI on a stream at any given time. Withdrawal is mandatory to prevent UBI being sent to addresses that did not consent to a stream.

  • The sender will see his/her balance with the discounted UBI being streamed on real time.

After extensive research, we currently have a working version on https://github.com/JuanuMusic/ubi/tree/UIP-1-Sablier — Even though we expect to work on additional tests, we will have a final version once the UIP reaches Phase 3.

These are the current tests for the streaming features of UBI v2:

 UBI streams
      ✓ require fail - Creating stream of UBI per second higher than UBI.accruedPerSecond should fail.
      ✓ happy path - After creating a stream that starts in the future, human should accrue UBI until stream starts.
      ✓ require fail - Creating a stream from a non registered account should fail.
      ✓ require fail - Creating stream to an existing valid stream recipient should fail.
      ✓ happy path - While stream with full accruedPerSecond delegation is active, human should not accrue any UBI and stream should accrue.
      ✓ happy path - When human stops being registered, stream should stop accruing.
      ✓ require fail - Creating a stream from a non registerded human should fail
      ✓ happy path - Creating a new stream after one has finished should not increment the number of active streams
      ✓ happy path - Creating a new stream while others are running or pending should increment the number of active streams
      ✓ happy path - Creating 2 streams with half accruedPerSecond per each should accrue the same value.
      ✓ happy path - Creating 1 streams with half accruedPerSecond should accrue half for the stream and half for the human.
      ✓ require fail - Creating 2 overlaping streams that, when overlaped, sum more than the allowed ubiPerSecond should fail
      UBI stream withdrawals
        ✓ happy path - After stream is finished, and recipient withdraws the balance, stream balance should be 0 and recipient balance should be the stream total
        ✓ happy path - After withdrawing from an active stream, balance should be 0 right after, but keep accruing until the end.
        ✓ require fail - Withdraw more than the stream balance while its active should fail
        ✓ require fail - Withdraw more than the stream balance after stream finished should fail
        ✓ happy path - Withdraw in the middle of stream and after it finished should add the total delegated balance


Since this implementation will require an interface that helps a user manage the multiple streams his/her account might be involved with, a specific dapp will developed and implemented to facilitate the interaction with the UBI v2 smart contract.

Next Steps

If this proposal reaches Phase-3, we will have a deployed version of the UBI v2 smart contract on Kovan so anyone in the community can interact and test it.


Woah! Such a simple change but so impactful! I love it. Wealth redistribution from the get go and the ability for us to support each other in times of need. THIS is what it’s all about :pray:

Thank you @juanu and @santisiri for your consistent work.


i love it too, nice idea !

I consider that delegation drip is the real game changer for UBI, and a vital, top priority implementation.

Some brainstorming on things it will probably enable in the future:

Recurring payments for services (i.e. Alice could delegate X hours of drip per month to an online video provider without sending a tx every month)

Drip colaterilized loans: it could enable borrowing without further collateral than the drip. Or a loan partly collateralized by the drip. If you dont repay the loan, part of your drip could be used as collateral. Furthermore, it could enable other to act as guarantors.

Easier Donations: you can donate X amount of ubi to the Organization/Person you would like to help.

Just a doubt I have, maybe its too early to answer ir: will the delegation cost gas fees?

Great job on this very important proposal, you have all my support


The act of delegating would cost some gas, but the address receiving the UBI won’t have to pay for anything. The UBI will suddenly emerge there, drip by drip.

Something @juanu mentioned me that could be very interesting is the following:

delegate(address, percentage)

If you can delegate a fraction of your stream, then you can do multiple delegations to multiple targets potentially.

This could be a very powerful financial tool as well. I’d be careful about the extra complexity this could bring in terms of development.


Yep. This could open new possibilities. Congrats!

Sounds like a very good implementation to me.
To encourage the entry of new profiles, I had the idea that the deposit would run on the part of the vouchers, this function would serve to compensate them for that deposit.
During the first drip days, the UBIs could go for the voucher that financed the deposit of the new registered human.

This is a fantastic move, and just what I’ve been waiting for in terms of streaming to climate change projects. Love it! :slight_smile:

1 Like

Hi everyone, just a quick update on how UIP-1 development is moving forward:

  • With @juanu we started developing an EIP 1620 (EIP-1620: Money Streaming) compliant version that works within the token contract itself. But this standard got deprecated since it was never merged in the EIP repo.

  • We reached out to the Sablier team (https://sablier.finance/) who are largely responsible for that EIP and we’ll likely adapt our contract to meet their same code standards so we can make this compatible with their implementation.

  • We are currently pushing code on this branch: Commits · JuanuMusic/ubi · GitHub

We are optimistic about the outcome of this.


This is really exciting, it opens up a new design space!

Just for completeness and inspiration, Superfluid is working on programmable cashflows, their approach is based on upgraded ERC-20 tokens and a Constant Flow Agreement.



Indeed we are! Its taking quite the Hard work but looks like all this research is taking us to a good solution for delegating Dripping UBI. We are also taking into account that this has a good UX for both users and developers


If it can be cancelled, this would just bloat the contracts for features which could have been part of an external streaming contract.

However, allowing to direct a stream in a way which cannot be cancelled until a specific amount of tokens have been streamed is interesting. This would allow people to borrow using their stream as a repayment guarantee.


Not entirely. Cancelling a stream means just stoping it from acruing value from the human sender, but keeps the balance available for the recipient to withdraw.

Also, recipients can check how much balance has been delegated from a given human address. This gives contracts the oportunity to act accordingly if any any requirements of a specific value is not met.

It’s up to the contracts to act on cancellations/total amount not achieved.

Streams are delegated by:

  • Amount of ubiPerSecond to delegate ← Cannot be greater than the remaining available ubiPerSecond to accru/delegate
  • Start time (when should streaming start)
  • Stop time (when should streaming stop) ← This cannot be higher than registration expiration.

This proposal has been formally passed to Phase 2 and is available for voting on the UBI DAO Snapshot

You can see the latest changes to it at the top of this thread.


I involuntarily made a mistake in the configuration of the DAO replicating the features of the PoH DAO and included delegations in it. This was a mistake since that shouldn’t be the case with the UBI DAO since that feature was not voted in.

I created a proper poll here: Snapshot and removed the previous one.

Apologies to the community for this silly mistake.


Amazing new systems in the works! Excellent to see everyone putting in so much time & effort.

Just to clarify a concern, are there any conflicts between the new UBIVOTE system and how it interacts with the proposed Delegated Streaming system?

I.E: Does delegating your $UBI to another user reduce the hourly increase in democratic power your votes have over time? It would be a shame for people to be conflicted between their own democratic voting power & the choice to delegate to another user for a meaningful period of time.

Also, good idea with the square root system for UBIVOTE! It helps mitigate people delegating their UBI to one person in order to increase a single person’s voting power (as it’s more lucrative to just keep their own tokens and vote)

1 Like

Well, the UBIVOTE proxy token will simply look at your UBI balance and calculate the square root…

if you are streaming say 20% of your UBI to someone else, then your balance will have 20% less UBI in it, thus impacting your voting power on the UBI DAO

but think about this: a good use case for streaming might be delegation of power itself! the community could organize around a leader and stream power to that person… making that person influential in the decision making process of UBI and able to challenge UBI whales (like myself :sweat_smile:)


I thought about it as a good use-case, but as we use a square-root system, wouldn’t it be a little inefficient to delegate UBI to increase another’s voting rights?


2 people have 10,000 UBI and their vote is worth more separately as two 10k votes, than one 20k vote.

√10,000 = 100
x2 = 200 UBIVOTE

√20,000 = 141 UBIVOTE

Positive: Mitigates a group (or person with multiple successfully registered accounts) being malicious by creating an individual with a lot of voting power

Negative: Makes delegating UBI to a genuine, influential individual for increased voting power inefficient

Perhaps there is a tweak somewhere to increase the efficiency of, as you said, streaming voting power?

But otherwise I LOVE the work so far: Delegate income & potentially democratically delegate voting power! Shaking up the world one code line at a time :pray: !


Woah… the more you learn. You are right!

Indeed it’s more wise to keep the UBI for yourself in the governance of UBI DAO… this makes the route of buying UBI still the best route to increase voice power (which at current prices, might be a good move imho… fwiw i did buy to vote on the first UIP).

Let’s keep in mind that the bottom line here is to find more and more ways that make UBI valuable. I’d like to unpack a bit more @clesaege’s ideas on how UBI credit could work with streaming.


An infinite approval to an streaming contract would have the same effect (note that you’d still save some gas as it would not be necessary to call the contract often, but for saving gas in really edge cases, you lose gas in the common ones).

From my understanding, the UBI DAO would take the same parameters/options as the POH one unless specified otherwise. Also delegations are not really a voting method but an UX one (it’s possible to set up a bot to copy vote on another user, the snapshot module just makes that easier). So from my understanding delegations should be counted.

Taking the square root is done before counting for delegations so there is not such an issue.