Giter Club home page Giter Club logo

Comments (10)

innsmouthrain avatar innsmouthrain commented on July 24, 2024 2

Consensus from our last retreat in NYC was that issuance rate should be changed community-wide through physically held meetings for this pilot

This is of course a super interesting topic that we will want to explore further outside the scope of the pilot.

from circles-contracts.

ana0 avatar ana0 commented on July 24, 2024 1

Sorry I gone and wrote an essay

from circles-contracts.

Jake-Gillberg avatar Jake-Gillberg commented on July 24, 2024

moth 7:13 PM
"The reason I thought it would matter I got from when we talked to the Rules' lawyer in 2017. She said if we would run on old world centralized tech we would get jailed, the reasoning being we can alter people's accounts and as such are acting as banks."

Do we have to worry about this if we are able to change the issuance rates? If we have the ability to "drop it to 0" or "increase it to infinity", would that mean we are "altering people's accounts"?

@innsmouthrain Would my proposal above fulfill the "community-wide through physically held meetings" criteria? I know for the pilot we are thinking of creating a registry with trust relationships to all of our on-boarded users. We will then approach vendors and tell them they can trust everyone we have registered. We could announce via physically held meeting that we are now "accepting an issuance rate increase of X", and update our registry so that when users manually increase their issuance to x (which could be done next time they open the app with an app update), the trust relationship with the registry wouldn't be broken.

from circles-contracts.

edzillion avatar edzillion commented on July 24, 2024

@Jake-Gillberg this is a very interesting proposal.

Do we have to worry about this if we are able to change the issuance rates? If we have the ability to "drop it to 0" or "increase it to infinity", would that mean we are "altering people's accounts"?

This is a serious issue and we should ask a legal person asap.

In general I think it might help if you describe your motivations for such a system. What would a multiple-issuance system look like and would it not violate a core principle of Circles: A monetary system where money issuance is equal between all users

from circles-contracts.

JuliointheStudio avatar JuliointheStudio commented on July 24, 2024

The issue I see with having different people with different issuance rates would be that the parity between all users value will change. If you have some users whose money is worth more than others, then we have a problem. How to maintian the parity/equal value of money between users while allowing for your proposal Jake?

from circles-contracts.

edzillion avatar edzillion commented on July 24, 2024

If you have some users whose money is worth more than others,

This isn't a direct outcome of differing issuance rates. They would just have different amounts. Given two similarly productive people, the person with the lower issuance rate's currency would tend toward being worth more than someone with a bigger issuance.

If we ended up having a really clear split between two camps, one of which had refused an issuance increase and these camps were easily identifiable by the users then you could have a situation of two exchange rates. In reality there would probably be 80% of people with the current issuance, and 20% with a mix of lower rates (many of these accounts may be inactive) - this is a much less clear system for users to make value judgements of peoples currencies based on some kind of categorisation.

from circles-contracts.

Jake-Gillberg avatar Jake-Gillberg commented on July 24, 2024

How to maintian the parity/equal value of money between users while allowing for your proposal Jake?

IMO we can't. You can't stop these sorts of trades "uneven" exchange rates from popping up unless you have controls on where / how people can spend this currency, but I don't think we want to go this direction.

I think the best we can do is create social norms / system defaults of 1 to 1 exchange rates.

This "who has the ability to change the issuance rate of their currency" question is an interesting one, because we are asking "by who's responsibility / authority do these system defaults change". My current preference is that the sole authority to make these changes lies on the individual currency creator, and it is up to us (the Circles team) to communicate and support proposed "defaults".

from circles-contracts.

ana0 avatar ana0 commented on July 24, 2024

IMO we can't. You can't stop these sorts of trades "uneven" exchange rates from popping up unless you have controls on where / how people can spend this currency, but I don't think we want to go this direction.

I think the best we can do is create social norms / system defaults of 1 to 1 exchange rates.

I'm agree with all of this, actually and my biggest concern for circles is that we'll fail to adequately seed these social norms.

For the global-community-set issuance rate - I'm assuming this is going to be stored in some contract. Maybe a global vars contract, maybe a library that other tokens are proxies of .. either way, it seems to me it should only be updatable via multisig. Who are the trustees of the multisig keys? How many of them there are? They should probably be representative of circles users, but how are they chosen and how do we determine that?

As for user-set individual issuance rates .. there are things I like about this idea. I like empowering users, and I like decenter-ing power. We could allow for a user override here, and then flag/alert users who are trusting someone who's chosen to not use the global rate (is higher, is lower, divergence of more than x, any divergence, etc). But then do we also allow users to override the flag/alert? What is the incentive to override here ... disbelief in and disenfranchisement from the circles governance processes? I like to keep in mind that we can never stop users from forking our work - we can only ever make it harder or easier. It seems to me there's an upper bound on the ways we are obligated to make it easier.

Biggest danger of this whole thing is scope creep. For the purposes of the pilot, what are we actually hoping to test? @JuliointheStudio mentions a set of hypotheses in his recent research roadmap ... think defining those will be helpful in knowing how far to travel down any of these particular rabbit holes

from circles-contracts.

d-xo avatar d-xo commented on July 24, 2024

not violate a core principle of Circles: A monetary system where money issuance is equal between all users

A variable issuance rate seems most interesting at a global scale, where a Circle in e.g. Switzerland will probably have a different purchasing power from a Circle in e.g. Liberia. So in this case a variable issuance rate would guarantee an equal purchasing power between all users instead of an equal issuance rate.

There does not appear to be a clear consensus on:

  1. Whether this is desirable
  2. How this would be achieved

As the pilot will only be run in Berlin, a single global issuance rate for all users seems sufficient.

How that issuance rate is set (and modified) is a hard problem by itself. Most of this kind of decision making will happen off chain (and I don't think any amount of fancy smart contract engineering will change this), so we should try to create spaces where users can be involved in the decision making process as much as possible.

I think the best we can do is create social norms / system defaults of 1 to 1 exchange rates.

I would also agree that good governance will always rely on strong social / community norms and our focus early on should be on defining and spreading these.

from circles-contracts.

ana0 avatar ana0 commented on July 24, 2024

Closing because I think consensus for a global issuance rate remains

from circles-contracts.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.