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
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.
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.
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.
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.
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.
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.
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.