UBIv2 status and the last piece of the puzzle

DAO
1

Hello Humans! On this post I want to give a quick update on the status of UBIv2, and the last piece that needs to be solved in order to move forward to testing and auditing the contract.

As some of you may (or may not know) the last couple of months have been a bit crazy on the development of UBIv2. The streaming features turned out to be a very interesting use case for some developers, and I have received many comments, questions and even proposals, on how it works or how it should work.

A couple of iterations occurred and different ideas for implementations occurred. This lead to a constant refactor of the contract Streaming features.

  • First, there were Sreaming features on the UBI contract
  • Then, a refactor to turn Streaming features into NFTs, on a separate contract
  • Then, a new proposal by the 0xdelyver team to create Flows instead of streams. This last proposal basically changed how Streams worked, allowing to make cheaper delegations, but with different features.
  • Given the previous proposal I came up with the Idea of turning UBI delegations into a modular thing, allowing delegations to be basically Plugins to the UBI smart contract.

UBI Delegator Plugins
The last iteration basically allows for any arbitrary contract that implements specific code, to be used as a Delegator mechanism for UBI. In order to plug in a new delegator implementation, a UIP would have to be voted and accepted by the DAO. This would allow to have specific implementations for bridges or other not yet known use-cases.

The last piece to be solved
The last piece to be solved is not tied to the Plugin mechanism, but its an inherent issue that UBI delegation brings.
Whenever a human is removed from the registry (by expiration or challenge), a function called reportRemoval has to be executed on the UBI contract to make that account stop receiving the UBI. The accrued UBI is then given to the caller of the function. (Accrued is the “virtual accumulated value” that is not yet part of th account’s balance) This is currently implemented on the UBIv1 contract.
The problem that we need to solve as a community, is that the implementation of UBI flow delegation, needs to have a defined mechanism about how to deal with the reportRemoval, when UBI has been delegated. The following are possible scenarios, with their pros and cons:

A word of advice: Keep in mind that in order to understand this scenarios, it’s required to understand how accruance, and reportRemoval work on the current version of UBI. If you need to better understand this, please, ask in the community. There are many who already know how this works.

On reportRemoval, delegated UBI is given to the caller of the reportRemoval function
This is basically the way that the current version works. Giving the accrued UBI to the function caller, is a basic incentive to make someone who whould not be receiving UBI, stop receiving it.
Pros: The incentive to execute the reportRemoval function is intact
Cons:

  • Protocols implementing UBI delegation as collateral might not be very motivated to use it, since they risk losing their funds, even when the UBI is delegated.

On reportRemoval, delegated UBI remains on the delegated account
The main idea here is that the implementor of the protocol can keep some guarantees about the accrued UBI.
Pros: The protocol implementing UBI delegations is guaranteed to keep the accrued UBI, if the profile is removed.
Cons:

  • A malicious actor could register and immediatelly delegate their UBI to another account, skipping the risk of losing their funds if the profile is challenged. (Think of farmers)
  • There is no incentive for anyone to execute the reportRemoval function.

It’s also worth mentioning that whatever needs to happen on the reportRemoval function call, can be implemented on the delegator contract, so it could be different for each implementation, but the multiple scenario should be taken into account.

The Arbitration Option
The is also a 3rd option, which seems to be the most viable. As @santisiri put it in simple words: “Just use Kleros” . This would basically mean: The delegator implementation would do whatver they think is best: Either give it to the reportRemoval callr, or keep it on the delegated account, but both cases should allow for a challengeable window in which, if someone challenges the expected result, it ould go to a Kleros court to be resolved.

Final Words
After solving the last piece, the UBI update would include:

  • UBI contract Update with the Pugins system
  • Streams Delegation (by Me) implementation, which allow for scheduleable delegations, and accrues UBI on the NFT
  • Flow Delegations (by 0xDelyver), which allows for instant delegations, straight to the wallet of the Flow NFT holder, No schedule, but cheaper gas fees.

All of this would be detailed on the UIP-1 Phase-3 vote, but before going there, we need to go through a few more steps:

  • Solve reportRemoval mechanics
  • Contracts auditing
  • Testing

Feel free to leave your comments, questions, or feedback.
:slight_smile:

4 Likes
2

Personally I would lean to the simplicity of the current mechanism where the reporter gets the ubi.

Those lending based off future income will likely being doing so because they can profit by charging a % on top of the loan to be paid back. Requiring a little risk and investment from them isn’t a bad thing imo. Places that use future promised ubi as collateral would have an extra incentive to be running checks themselves: checking the quality of submissions on poh, calling reportRemoval on ubi themselves

3 Likes
3

My hunch is to keep it with the current mechanism of giving delegated UBI to the caller would be the best.
I feel like the second option has more cons than pros.
The third case of bringing the case to Kleros will bring about the issue of who will pay for the court fees and, how much the fees should be. My hunch is that the viable challenges (where the rewards justify the challenge fees) will only be the expiration cases, as invalid profiles normally get challenged before they accrue enough UBI to make challenges worthwhile. The subset of profiles who are expired and have delegated their UBI may be so small that it might not justify the effort to add the option to bring it to arbitration.

2 Likes
4

Hey! Thanks for the response.
As some already know, I am thinking of making the first UIP to only deploy with FUBI since its the less complex and most useful (because it allows us to build the UBI dripping bridges).

Taking this into consideration, I was actually thinking of going thge other way round, and keeping the UBIs on the delegated account instead of to the caller.
This is because, If we want to have bridges, once UBI has been delegated to the bridge, it needs to be locked there. If not, we are basically generating a DOUBLE MINTING.
Bridges acccrue the actual UBI, and they send that info to the L2, where UBI is minted on that L2.
If we give the accrued value to the caller, tehre is no guartantee that the UBI on the L2 is still on the owners account, so we can’t “remove it”. Basically creating this problem.

I think the way to go is to actually make it as simple as possible, so we can have a trustable L2 bridge and be able to drip UBI on L2

2 Likes