We were brainstorming about ways to enable Group Currencies with the current version of Hub.sol
When using a transaction batch mechanism, like the Gnosis Safe Transaction Builder, this can be achieved quite easily. This approach will use a Token Swap mechanism, which then enables the original Token sender to exchange the swapped Token for Group Currencies.
Scenario: Alice wants to swap her CRC for BobsGroupCurrencyToken
Bob trusts Alice and is member of BobsGroup, which uses the BobsGroupCurrencyToken. This means that Bob can always exchange his CRC for the BobsGroupCurrencyToken.
Alice wants to exchange some of her CRC for BobsGroupCurrencyToken, but is not member of BobsGroup. As she is trusted by Bob she could use Bob’s Tokens to exchange those for BobsGroupCurrencyToken, but currently there is no way of swapping Tokens in Circles.
For Alice to acquire BobsGroupCurrencyToken, this sequence could work:
- Alice swaps her Tokens for Bobs, so she sends Bob her CRC and gets Bob’s CRC back. This might be transitive (Alice sends Bob via Charly but still gets 1:1 Bob Tokens)
- Alice uses
mint or mintDelegate on the GroupCurrencyToken to mint BobsGroupCurrencyToken for the Bob Tokens she received
For the first step, one possible implementation would be a Universal Receiver contract which allows (unrestricted!) fetching of Tokens which have been sent to it. This contract is an org account which trusts all users in its Group. As the fetching of transferred Tokens is unrestricted, the transfer step and the claim step must be bundled in one transaction batch.
Once Alice owns Bob Tokens by swapping her Tokens via the Universal Receiver, she can call mint or mintDelegate on the GroupCurrencyToken. This step does not have to be in the former atomic (batch) transaction, but could be, to provide better UX.
The transaction bracket is created with an external tool, eg. the Transaction Builder in the Gnosis Safe.
Thanks for the write up @alculexum
Here is a slight additional improvement building on the same idea.
This concept does not need the “universal receiver contract”. Instead the group currency contract itself registers as an “org-account”. It will then need to trust accounts. Now, a regular hub-transfer (transative transfer could be done to the gc contract. (Step 1). As a result of this the GC contract would hold in this example CRC of person C. After this a mint function would be called from A. Note, this mint function can be called from anyone and therefore it needs to be called atomically together with the transfer - otherwise any account can esentially steal the group currency by minting it themself. The mint function would be called with only the token adress (in this case c-CRC) as parameter and it would simply check the balance of c-CRC of the GC contract itself. Next it would mint the same amount of GC to whoever called the mint function (in this case A) and it would transfer the c-CRC to the treasury.
1 Like
Nice, that sounds better and there has to be no Universal Receiver. I will prototype this somewhen this week, should be straigthforward.
I implemented this in an other branch (hub-v1-comp) with @martin_koeppelmann suggestions. Seems to work, I only tried local testing against Remix VM and Ganache, both worked. The test scenarios are included in the README: circles-contracts/GroupCurrencyTokenReadme.md at hub-v1-comp · ice09/circles-contracts · GitHub
Now this would have to be deployed on the Mainnet, tested with a real trust graph and also the batched transaction test is still missing (as I can’t get the safe running in a local testnet).
1 Like
While implementing the Prototype, some questions came up. I leave those here, maybe these can be discussed on Friday?
Options for GroupCurrencyTokens
Current Implementation
In the current prototype, if Charly is member of the Group (ie. the GroupCurrencyToken (GCT) trusts Charly directly) and trusts Bob who trusts Alice, Alice can swap her CRC for the GCT by doing a transitive transfer of her Tokens to the GCT, which results in Charlys Tokens being stored in the GCT.
Alice can then (in a batched transaction) claim GCT for Charlys Tokens, which will be burned (transferred to the Treasury).
Pro
- Group members are forced to pay close attention to their trust graph
- Fine grained control over total supply of GCT
Con
- Group members cannot really be sure about transtive dependencies
- Cannot really scale without growing Group fast
Assumption: If GroupCurrencies are implemented this way and some price for GCT will occur, the Group members CRC will be drained immediately by transitively trusted users.
“Self-Swap”: Only use permission to swap with trust graph
In this option, Alice still sends her CRC to the GCT directly (which is only possible if a trust connection exists). She can then swap her CRC for GCT.
Pro
- Charlys CRC are not drained
- Control over supply is still possible by untrusting Alice
- Can be scaled easily without having to permanently grow the Group
Con
- Charly is not responsible with his own money
- Total Supply is more difficult to track
With this option, direct Group members are more “gate keepers” of CRC minting.
Veto for Swaps: Group member has to accept swaps
With this option, either the self-swap or the transitive swap are implemented, but the Group member actively has to confirm the swap.
Pro
- More control, draining is not possible easily
Con
- Not automated, not really rule-driven
Supply is capped for Token Swaps
The Veto could also be stated beforehand by the Group member or by the GCT itself, so only a certain Max amount can be minted (by account, by all members, …). This amount might be fixed or could be adjustable by the DAO. If it is fixed, scaling could be done by creating new GCTs, this would keep the price stable and trust level high (“the Bitcoin way”).
Pro
- Rules are pre-defined
- Supply is capped
Con
- More administration and work by the DAO members
Thank you Alex.
I feel all 3 variations can be valuable.
- Current Imp (anyone can mint but only use member CRC)
I think this is a clean solution. The 2 “cons” you list:
a) Group members cannot really be sure about transitive dependencies
Hm. I think the consequences are clear enough. Yes - people from far away can transitively enter the group, and yes, this can mean that CRC from group members will be “drained” into the group. However note that: a) this can/ will happen even without groups. Let’s imagine there is a popular merchant that accepts a number of CRC users the same effect will happen. People from all over the trust graph will buy at the merchant and essentially the CRC of the user trusted by the merchant will flow to the merchant.
However - note that there are clear limits to this. The effect of outsiders being able to mint GC can very well be limited. E.g. if I only trust people part of the group I will never be affected by having my Circles drained. But even if I trust someone outside of the group - as long as this person is trusted by many within the group it is quite possible that I can find a path from those CRC to group currency. In the example attached the total amount of GC that can be minted is 500 but the number of GC that can be minted by the transitive network outside is limited to 300.
b) Cannot really scale without the Group growing fast.
That can certainly be a plus. Therefore e.g. the total capital required to keep the GC stable can be known. But if the group wants to scale faster it can certainly find ways to even programmatically add members. E.g. there could be a rule that anyone can add themselves to the group if they are trusted by at least 3 members.
-
I think this is only useful if you can limit the length of the path. E.g anyone who is trusted by the group (1hop) or at max 2hops. If ANY path is sufficient the group becomes useless as in the Circles trustgraph usually anyone is connected to anyone over some path.
-
Veto for Swaps: Group member has to accept swaps
I would call that simply: only group members can swap. That can certainly be a useful alternative. Specifically, if there is some kind of expectation to use the group currency only in specific cases.
Hi @martin_koeppelmann thanks for commenting,
there are four options? But arguably the “Cap”-option is not “standalone”.
Let’s imagine there is a popular merchant that accepts a number of CRC users the same effect will happen. People from all over the trust graph will buy at the merchant and essentially the CRC of the user trusted by the merchant will flow to the merchant.
Yes true, but just from practical reasons I think it’s not the same. I will buy something from the merchant and then I am happy, so I’d really have to be a bad actor to abuse this.
For money, it seems not the same to me. As soon as there is a price for the GC, all “gatekeepers” will be drained (and I’d argue immediately).
So for me, let’s say I am a “gatekeeper”, you trust me and are in the group, I have 100 CRC. I trust a very good friend of mine. He trusts his brother I barely know. The brother trusts his wife I don’t know at all. She can use my 100 CRC (or at least 50 for the initial limit logic) to convert to 100 Dai with Honeyswap? Sounds to me I’d have none of my own CRC left faster than I could count to 10…
I think this is only useful if you can limit the length of the path. E.g anyone who is trusted by the group (1hop) or at max 2hops. If ANY path is sufficient the group becomes useless as in the Circles trustgraph usually anyone is connected to anyone over some path.
Yes, that sounds even better to me, having a direct trust rule here, so anybody who is trusted by someone of the group directly can swap her own CRC, right? (or 2 hops, 3…)
