Regarding our upcoming Munich Pilot of Circlesland, we stumbled upon a few challenges in the core HUB and TOKEN contracts and would like to start working towards a new Circles 2.0 contract update.
We should also as well split the minting and transfer related topics (HUB 2.0 contract) from the web-of-trust (TRUST 2.0. contract) topics.
The challenges we encountered are the following:
1a) transferThrough is too restrictive and needs to be fixed in its limitation.
During optimizing pathfinder related challenges, we found out the following problematic behavior in the transferThrough() method. Let’s imagine this. Alice is joining at day 1, Bob is joining at day 10. Alice has f.e. collected 1000 A-Circles until then, Bob has only collected 100 B-Circles so far. When Bob now trusts Alice 100%, we would think Alice should be able to send all her 1000 A-Circles to Bob via the transferThrough() method, but Alice can send only 100 Alice Circles, since inside the checkSendLimit() method the current calculation of the “max” value, depends on Bob’s own holdings of his own B-Circles.
The result of this behavior is that, in case Alice would have send all here A-Circles to someone directly, she wouldn’t be able to receive any more Circles at all transitively, but her own personal Circles.
If you decompose this line of code: https://github.com/CirclesUBI/circles-contracts/blob/0654dcc2a361c0736aa8c3553afd02b66263f940/contracts/Hub.sol#L229 you’ll find that the transferrable amount depends on the holdings of the receiver’s own tokens:
userToToken[dest].balanceOf(dest) // Dest's balance of his/her own tokens
.mul(limits[dest][tokenOwner]) // multiplied by Dest's limit of the tokens in transfer
.div(oneHundred) // divided by 100
1b) Binary trust only
transferThrough should make trust binary, ether there is trust or not (remove the % trust limits).
2) Remove the 90 days deadman switch
As you all know, many users experience the problem of running into the 90 days deadman switch. We propose to completely remove this.
3) Shorter inflation rate intervals
Currently the 7% yearly inflation rate is calculated and updated only once per year, creating quite large jumps from one time interval to another. We propose to split this over the course of the year and do weekly update calculations.
4) Compatibility with group circle contracts
Regarding the first prototypes of Alex’s group circles, we found out that it is not possible to transitively change individual circles into group circles, because of some restrictions of the original HUB contract. This has been fixed in a fork by Alex and should be integrated into the 2.0 version.
5) Migrating balances
Regarding migrating old v1 balances into the version 2, we suggest adding to the signup method a second migration method, which allows existing v1 users to signup with their original v1 safe. In this process a new token will be created and all balances will be copied from the V1 Token to the the new V2 token. For this process, we can define a transition period of f.e. 3-6 months, where the migrate method is active. After block n, it should revert when called. Migration should be only possible to call once for each token migration.
6) Migrating trust relation (re-running them on the new trust contract)
Regarding the process of updating existing trust relations from the HUB 1.0 to the TRUST 2.0 contract, we propose a script on the client, which is re-running individually all the personal trust relations, after a client is upgrading a token from v1 to v2.
7) Add a follow trust method to the TRUST 2.0 contract
Any user or orga should be able to follow trust any other safe. This can be documented via the blockchain events startFollowTrust and stopFollowTrust. The transferThrough needs to pick up those relations as well.
Other open Topics to be discussed:
- Do we need or miss any other indexing events that should be added?