Circles Contract v2

Circles general
1

We are getting closer to a v2 version.

The main features include:

  • 1155 based
  • native demurrage (1 CRC/h)
  • trust is binary (no trust limit) but has instead an expiry date
  • group currency is natively supported (can trust groups to swap CRC 1:1 against group tokens)
  • removing the 90 day lock
  • minting has to be done by user itself, can only mint for the last 2 weeks (i.e if you don’t mint at least every 2 weeks you “miss out”)
  • ability for create demurrage or inflation ERC20 wrapper for any CRC
  • more flexible “transferTrough” that can wrap into group currency on the transaction
  • migration from v1

1155

Previously every user would get it's own token contract (ERC20). In Circles v.2 this will be more elegantly solved via a single contract that can hold many different token types. It makes it more easy for a user to interact with a large number of different token they hold. In addition 1155 allows contracts to define actions they do on receiving. This can include things like: defining which tokens to accept at all (based on the trust graph) or trigger arbitrary actions.

Native demurrage

In Circles 1.0 the actual issuance started at 8 CRC per day. This would increase every year by 7% (one step per year). 2 years ago we decided to transition to "time Circles" - fixing the issuenace to 1 CRC/h and instead of increasing this issuance by 7% - reducing all balances by 7% per year. Perviously this conversion was done only on the frontend. Now - this is done on the contract itself. Internally the contract will still use the "inflation" mechanism and start (looking backwards to the v1 launch) at 1 CRC per h. This issuance rate will get increased by 7% per year - though more continuously (daily a small increase). However - externally (get_balance, transact amount) all numbers will be adjusted to 1/CRC per h. The consequence will be that any account that does not mint or receive Circles will have a balance that decreases by a small amount every day. Because this can cause challanges with other contracts or accounting software - there will be an option to wrap those balances into an ERC20 token that uses the static inflation representation.

Trust

Previously persons could trust each other with a trust score of 0 to 100. This was intendet to indicate how much of their Circles a person would accept. However - the concrete implementation would require you to hold your own CRC first to accept any other. If your own where currently not reachable a person could not accept any CRC whatsoever. So now, trust is binary, but instead one can set an expiry date.

Group currency

Previously one could register as a human or an org in the Circles trust graph. Now there is a third option: a group - or more technically "a Circles collection". The basic idea is that those are new type of Circles that represents a mix of underlying other Circles. It is meant to not increase the overall supply of Circles - as to mint a group circles it is necessary to lock another Circle (group or individual). The rules of how to mint or how to go back (redeem) can be defined flexible.

90 lock and 2 week mint window

Previously, if an account would not mint for 90 days is got permanently locked and could not mint anymore. This was meant to automatically "close" the account in case of a lost key to now safely create a new one. This had 2 problems - first, many people ran into that state even if they had not lost their key. Second, theoretically, if someone had lost this key this mechanism would not reliably close the account as anyone was able to call the mint function. In Circles v2 we are making two changes: the permanent lock gets removed (user itself can still actively "close" the account). On the other hand, now only the user can mint and they can always only mint for the last 2 weeks.

ERC20 wrapper

We expect most personal CRC to be simply held within the 1155 representation. However - once CRC - most likely group Circles - interact with outside protocols (DEX, lending, market place) - ERC20 is the more widely adopted standard. So it will be possible to wrap 1155 and the user can chose wether the use a demurrage (rebasing) version or a inflation (not-rebasing) version.

transfer Through

The previous transfer through function had some unnecessary restrictions. E.g. one could not send to multiple receivers in one transaction. We now try to allow for maximum flexibility as long as all core rules are upheld. As part of a path can even be the conversion from a Circles to a group that accepts this Circle as collateral.

Migration

All those changes are meant to make it easier to use and build around Circles. However - this is not meant to a re-launch. So all Circles balances can be converted to v2. Ideally a user would not have to notice a transition from v1 to v2. The biggest disruption will be that people have to recreate their trust connections. Interfaces can help with this and suggest users to trust others that they already trusted in v1 - or even do that automatically in one transaction.
4 Likes
2

Nice, well done! Looking forward to more.

Have you also considered adjusting the initial “signup bonus” to a larger amount, to get some more flexibility while starting out f.e. building some liquidity etc.

3

Invite logic

This is maybe a more controversial change.
In v1. anyone could register. This was necessary to bootstrap the system as we certainly did not want to put any of us in a privileged position at the center of the trust graph.

However - after now >100k accounts registered we could require an invite from someone already in the system onchain.

The mechanim would work as followes:

  1. there is a limit period of time (e.g. 3 month) in which anyone can take their v1 account and migrate it to v2. After that period you will need an invite (trust) from a person already registered in v2.

  2. In addition we thought that it might be an interesting twist that a registration fee needs to be payed - concrete idea would be to burn some of the tokens of the person inviting.
    Concrete numbers we have thought about: cost 100 CRC signup bonus 50 CRC

We like the idea of someone “inviting you” and even paying for your invite. Though in practise both options are possible - the inviting person actually paying or the person being invited paying the inviter “out of protocol”

What we see as a nice side-effect is that it is not possible to instantly create unlimited Circles. In the old scheme one could create instantly unlimited accounts that all get a signup-bonus and thus one can create instantly infinite Circles. This means if one can somehow “hack” a group and add (infinite) people to it one can instantly completely destroy this groups. The “pay to invite” mechanisms puts limits on growth. As adding a new person costs 100 but only 50 new CRC are generated it means that only after ~2 days the new person has generated in total 100 CRC.

In addition to the “spam protection” this mechanism ensures conectivess of the whole trust graph. While people can again “untrust” the chain will still record the initial connection.

@samuelandert
This proposed change would on the other hand make your suggestion more difficult to do. If we would increase the “sign-up bonus” to 1 week, 1 month(?) we would also need to increase the invite cost if we want to keep the “spam protection property”.

1 Like
4

While I like the requirement of paying for invites in Circles, it is only a temporary spam protection for the initial period of a malicious actor. Once someone gained access, they can still create over a longer period of time exponentially numerous fake accounts, just at an slower rate.

The way I would be able to game the system is (and probably I would even do as a user with “good intension”, in order to not pay the fee in my valuable circles, I would create one fake inviter account, wait for it to accumulate circles over time and then use those circles to create more regular invites for real “good-actor” and “more-inviter-only” accounts alike.

3 more proposals that would fix the above mentioned challenge:

  1. Medium governance layer
    Create 1 initial group circles currency and hardcode to pay the invites with those group circles. And then govern the group with a DAO and / or for a grace period with a simple multisig.

  2. Minimal governance layer / Hardfork only
    Another option would be to require xdai as invite fee, while preparing the contracts with potential future proof hardfork capabilities, where we would be able to update the invite token via hardforks.

Both options would increase the spam protection by an order of magnitude.

  1. Zero Governance layer - My favorite solution
    Being able to mint as many Time Circles I want until the upper limit of (~125.000), by providing liquidity against that token in xdai at a fixed rate f.e. 1 TC to 0.10 xdai.

Or in other words:
I pay anything between 10 and 12.500 xdai (or even better the dollar equivalent in weth) into a minting contract. The minting contract gives out respectively 100 to 125.000 TC in return. This contract also gives me the option to always change back my TC (by burning them) against the underlying weth or xdai at the initial base rate.

1 Like
5

Another “no governance” option would be:

“Entry fee” need to be payed in an “official” group currency - they way to become an official group currency is to provide at least e.g. $1000 xDAI liquidity against that group currency. (it would be a free choice at what CRC ↔ xDAI rate)

What I do like about the “mint more” CRC is that it can make the bootstrapping period easier. What I don’t like about it is that it seems we would need to set some CRC ↔ xDAI price - which seems very difficult to get right.

That being said - I think group currencies could in theory implement such rules that miniting would not only be possible against individual CRC but instead also against other tokens/xDAI

1 Like
6

To start with an official group currency is also a nice option, while to nail its hardcoded rules how to gain access to this, needs good considerations and is not so easy to nail. Not sure yet, if the group currency liquidity would be enough as a rule, need to think more about it. (I will do)

Regarding the “mint more” option, I don’t think that how we choose the hardcoded CRC ↔ xdai price is too important as long as it is not too high.
Anything between 1 xdai ↔ 10 or 100 CRC should be fine.
I see it just as kind of a baserate / minimum fallback rate, the goal of someone would be always to increase its base value through using their CRC as utility in various situations, f.e. with other liquidity pairs, in groups currencies, just the trust network or any other future community ideas etc.

I think having the flexibility to be able to capture as much value in all my own mintable Circles in the tempo I am able to choose, through whatever means I believe are best of, is a very powerful feature, that helps the adoption as you stated immensely.

1 Like
7

The more I think about this topic, the more I am in favor of building an official Circles Protocol Group Currency, which has a fixed rule set.

I am opening a new thread for this: