Hi Santi, first off, I apologize for using a github issue as a medium for communication. I had no luck trying the @democracy.earth emails or twitter account, which I emailed several times in 2020.

I was wondering if you could give an investor update. You can reach out to me directly and for reference, my address is 0x365...065.

The last update (in 2019) detailed plans for a $VOTE token architecture, which seemed to have been abandoned. I understand, but as a backer, I'm wondering at this point what I've funded. I'd prefer to have my funds returned or at the very least, a plan, a reply, really anything.

The current token design requires humans to call mintAccrued(address human) any time they want to claim their outstanding UBI balance. With the current gas price swings, that transaction is likely to cost tens to hundreds of dollars.

An alternate option is to have the ERC20 balanceOf() be a computed variable, based on incoming and outgoing streams to the address. Superfluid has built out this functionality already, so implementing this would be really simple.

Here is my review for UBI : https://docs.google.com/document/d/18N6XjOLeOBUDS__hXezZSuE2HNpFetFx-Dm5M1VKrp0/edit?usp=sharing

Steps to reproduce

Following the readme.md instrctions:

1. Clone Repository

   $ git clone https://github.com/DemocracyEarth/ubi.git
   $ cd ubi

2. Install Dependencies

   $ npm install

3. Run Tests

   $ npx hardhat test

Issue

Seems that there is a failing test at /test/sUBI.ts file:

  91 passing (1m)
  1 failing

  1) sUBI.sol
       UBI Stream cancellation
         happy path - when reportRemoval is executed, all existing and future streams should cancel and canceller balance should increase :

      There should be no active streams after reportRemoval
      + expected - actual

      -3
      +0

Steps to reproduce:
user 1:

1. registers on POH
2. execute startAcrruing
3. Creates stream with parameters:

• destination: user 2. (not registered on POH)
• ubiPerSecond : 10000000000000 (0.00001 UBI)

4. After some time, user 2 executes withdrawFromStream
5. try to get balance of UBI from user 1
   Expected result: Should correctly fetch UBI balance for user 1
   Actual result: Fails with the following error:

Error: VM Exception while processing transaction: revert SafeMath: subtraction overflow
      at UBI.sub (@openzeppelin/contracts/math/SafeMath.sol:102)
      at UBI.getDelegatedAccruedValue (contracts/UBI.sol:761)
      at UBI.balanceOf (contracts/UBI.sol:342)

I assume that since Sybil resistance is baked in, the UBI project would prefer to use a democratic governance model (e.g. 1p1v or quadratic voting (QV)), rather than a plutocratic governance model (e.g. token weighted voting).

For a UBI system, QV with the UBI token used as voice credits seems optimal.
UBI tokens spent on voting could be either:

1. Burned, putting deflationary pressure on the token supply.
2. Reallocated to public goods for the benefit of UBI token's ecosystem.

I'm not aware of any DAO frameworks that have implemented QV, yet. I'd suggest that one way to start might be to set up a Gnosis Safe multi-sig controlled by a geographically diverse set of known humans who agree to sign in accordance with a Snapshot instance with a QV template. Post launch, one focus that the DAO might take is to build a QV system that can eliminate the need for/dependence on the multi-sig signers, with the eventual goal of removing them.

I imagine the initial snapshot template working something like this:

1. burn() should have an optional parameter to add some extra data, the snapshot proposal hash (e.g. QmfYNxnWf62q988H7c8UzDnsp8XaNwBjjf1JXVSyyngkcf)
2. To get "voice credits" for a proposal, humans burn some amount of UBI tokens, including the appropriate proposal hash.
3. To vote, users sign a message via the snapshot interface

Note: burning could be replaced with a transfer to some public goods fund allocation mechanism, like an instance of clr.fund, for example.

Maybe it can be useful to inherit the UBI smart contract from BaseRelayRecipient.sol https://github.com/opengsn/gsn/blob/master/packages/contracts/src/BaseRelayRecipient.sol to allow metaTx.

Cons: more gas / more complexity

This is an idea for a new feature.

UBI holders won't necessarily have ETH to pay for the gas used in transactions nor the money to buy ETH. Implementing something like https://eips.ethereum.org/EIPS/eip-2612 into UBI token would allow low income users to transact UBIs in a gasless way by using signatures and letting the recipient of the transaction pay for the gas.

This one might be useful as well: https://eips.ethereum.org/EIPS/eip-3009.

I'm going to build a subgraph for the project, so more Dapps can be integrated.

https://docs.google.com/document/d/1FHmn5Xwk8ECfjV76YiqCNj39uLGNyBLd3qt-OWHdOs4/edit?usp=sharing

The link for ERC20BurnableUpgradeable.sol https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/token/ERC20/ERC20BurnableUpgradeable.sol is broken.

instead of having:

mapping (address => uint256) private ubiBalance;
(...)
mapping(address => uint256) public accruedSince;

you can do this:

struct UbiAccount {
  uint224 balance;
  uint32 timestamp;
}

mapping(address => uint256) public ubiAccounts;

and update everything to support this new structure (cast uint256s to uint224s, etc)

Rationale

Every time you transfer, you need to write to both slots. Assuming best case (non-zero to non-zero), the updateBalance(...) that is called will incur:

(2900 + 2100) * 2 = 10_000

if you however have both the balance and accruedSince in the same slot, you rewrite on dirty and hot:

(2900 + 2100) + (100 + 100) = 5_200

all in all, this amounts to 4_800 gas saved.