Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a document for NFT-based roles for CC #25

Closed
sirwolcott opened this issue Dec 14, 2021 · 6 comments
Closed

Create a document for NFT-based roles for CC #25

sirwolcott opened this issue Dec 14, 2021 · 6 comments

Comments

@sirwolcott
Copy link

sirwolcott commented Dec 14, 2021

Create a document for NFT-based roles for CC

NFT's are Non-Fungible unique identifiers or attributes identified by the Metadata in the token. They cannot be replicated and are unique to their owner and policy ID. They can live on chain as well as direct to an IPFS/host. NFT's can be paired in contracts using policy ID's, fungible tokens, oracles and wallet holders. The possibility's are endless with functions of NFT's and uses.

Basic content :https://developers.cardano.org/docs/native-tokens/minting-nfts/

@stephen-rowan
Copy link
Contributor

Have been doing some work. Learning how to use tokens for benefit of community. Voting methods using tokens. Interested in exploring how to apply to audit, treasury and roles. - Chris

@RaceSpeed
Copy link

Each Role in the Cardano ecosystem can be identified to KEY NFT's, roles, and wallets. Community roles can be identified by tokens and tracking of tokens.

@RaceSpeed
Copy link

Use tokens for Legacy and Transparency for participants in system/catalyst. Credit and immutable proof of work for teams who deserve recognition. Compensation measures to track KPI of members.

@RaceSpeed
Copy link

https://pool.pm/150217c1e72aeb12c9023f9f1b7d90c99531a4157b380023bad5d890/stake
Growing pool and testing Reward token structures and pulling data passages with API's to use relays and mints.
Testing lvl1 update.

@RaceSpeed
Copy link

VOTER Roles + Proof Of accountability + neither centralized
https://miro.com/app/board/uXjVOMES8sU=/
Thanks Stephen Tevo and all for After townhall

https://plato.stanford.edu/entries/social-choice/

https://slingerjansen.files.wordpress.com/2020/03/defining-blockchain-governance-a-framework-for-analysis-and-comparison.pdf

https://docs.google.com/presentation/d/1kfKrqdZB8v4oN2WY_nqDlGNB60s4u6iZjvpUKu5AQLU/edit#slide=id.g1158ea8c765_2_119

@stephen-rowan 2

C. Pareto Efficiency
Any blockchain governance system will necessarily depend on a number of decision-making procedures: individual,
competing preferences have to be collected and combined
into specific actions. The investigation of such processes is
the focus of Social Choice Theory [27], which is an entire
field of study dedicated to them. One of its crowning early
achievements is the famous Arrow’s Impossibility Theorem
(Arrow [28]), on voting systems where participants rank the
possible candidates. Specifically, given a set of alternatives
A = {a1, a2, . . . , an}, each voter i submits an ordered
vector of the form ai1 ≻ ai2 ≻ . . . ≻ ain
. Combining
the votes should lead to an outcome preference ordering
aj1 ≻ aj2 ≻ . . . ≻ ajn of the candidates that best represents
the voters. Unfortunately Arrow’s Theorem states that the
following natural properties cannot be satisfied at the same
time:
• If every voter prefers candidate X over Y, then X is ranked
higher than Y in the final outcome. This property is often
called unanimity.
• The order of X and Y in the final outcome depends only
on the ordering of X and Y in each voters preference,
irrespective of how all other candidates are ordered. This
is called independence of irrelevant alternatives.
• There is no voter who has dictatorial control over the
final outcome.
Variations of this result have been adapted in many voting
settings, even in cases where the voting process does not have
to reveal an entire ordering of outcomes (but only to select the
‘best’ one) or when voters have cardinal preferences (i.e. they
can assign numerical preference values to each candidate).
Note that almost all popular voting schemes (such as approval
voting, where each voter selects a set of acceptable candidates)
fall under these definitions. Perhaps the most famous of those
impossibility results is the Gibbard-Satterthwaite Theorem
(Gibbard [29], Satterthwaite [30]), roughly stating that any
voting scenario with more than two candidates is either
dictatorial, or subject to strategic voting (i.e., voters swaying
the outcome by misreporting their actual preferences.
To deal with these impossibilities, the voting procedures
used in practice are not required to be optimal in every
scenario, but to satisfy certain weaker properties depending
on the setting. One such mild property is Pareto efficiency
(e.g., [31, 32]). These properties are tested assuming every
voter truthfully reports their preferences.
Definition 5. A blockchain governance system is Pareto efficient if whenever a decision-making process is held, alternative X cannot win if there exists another alternative Y that is
preferred by at least one participant and no participant prefers
X over Y.
A Pareto efficient governance system would never lead to an
outcome that is clearly worse than another possible outcome.
This property should typically be satisfied (at least when
interpreted loosely, as some blockchain systems do not have
an entirely rigorous governance model), unless there is good
reason not to. Evaluating whether this property is satisfied can
be tricky because a blockchain governance system contains
many interacting components, with the final result seldom
depending on a single vote. We make our best effort to fairly
evaluate how likely it is that a Pareto efficient outcome is not
selected and how much worse is the selected alternative.
Approval voting is of particular importance, as it is the
most common voting mechanism used by the blockchains
we evaluate. Given n candidates, each voter can ‘approve’
as many as they want. The winner is the candidate which was
approved by most voters, often combined with a threshold,
such as also requiring approval from at least 20% of them.
Notice that even though the voters might have ordinal or
cardinal preferences, they can only submit a binary signal for
each candidate. Starting with a simple example, suppose that
2 possible incompatible blockchain updates a and b are up for
election. Furthermore, suppose that every voter prefers a ≻ b.
The outcome will be dictated by the threshold they chose
when converting their ordinal preferences to an approval vote.
Typically we would expect a to win, but b could win as well!
Clearly, any truthful voter who approved b would also approve
a, since a ≻ b for every voter. However, some voters might
chose not to approve either of them. In this case b could win
because of a tie. In fact, this is the only way an outcome of
approval voting might not be Pareto efficient: if the winner is
tied with the Pareto optimal candidate. This happened because
the voters where completely uniformed about the preferences
of each other and set their ‘approval threshold’ too high. The
more information they have the less likely such an outcome
becomes. A group of perfectly rational and informed voters
would always produce a Pareto efficient outcome. In addition,
it is important to keep in mind that there are two more
‘secret’ (implicit) options always available: to do nothing
or to fork, which is to be avoided. When combined with a
minimum approval threshold and some awareness on the part
of the voters, the winner is most likely either Pareto efficient,
a suboptimal yet highly popular alternative or a deadlock.
Finally, strategic voting involves setting the threshold very
high, which decreases the total number of votes and could
lead to a deadlock, but is unlikely to result in a fork.
We briefly discuss an alternative voting system that uses
the complete ordinal preference profile called instant-runoff
(IRV) voting. It proceeds in turns:
• From every ballot, only the top preference is counted.
• If one candidate obtains a majority, they win.
• Otherwise, the least popular top preference is deleted
from all ballots and the process repeats.
IRV is also not Pareto efficient as a good candidate might be
deleted early, if they fail to win many first choice votes. It
is however remarkably resistant to strategic voting [33] while
retaining some properties that approval voting lacks, such as
selecting the majority winner if one exists. This makes IRV
particularly appealing when the community is asked to choose
between alternatives in a non-binding way. The result can be
further ratified by a referendum.
In some cases, IRV (and any voting system using ordinal
preferences) might force the voters to inadvertently submit
misleading information. For example, IRV assumes that the
first and second place candidate on every ballot are separated
by an equal amount, whereas some voters might be indifferent
while others strongly in favour of their first choice only.
Approval voting sometimes gets around this issue by asking
for even less information. Ordinal preferences can be easily
elicited by an auction which is undesirable for an election. A
better alternative is to use an ordinal voting mechanism such as
majority judgment [34] or combine approval voting with token
locking: voters who feel strongly about some candidate may
lock their vote tokens for longer, indicating that this election
is particularly important to them.

Catalyst-Circle-Admin-Coordination automation moved this from In progress to Done Mar 18, 2022
@RaceSpeed
Copy link

Sad to see this closed.
This would have been nice to see "Done"
I will just fund the whole Ecosystem and tests myself
Maybe the Circle will run with more digestible ideas like- Does Pineapple on Pizza?
mindmapgov
Don't worry, I will put a proposal in and you guys can let it fail like everything else.
Then I will self fund it because you guys are useless in managing funds. You are lucky I am not in your meetings anymore.
The greatest part about plans like this one- Everyone is too stupid or busy to steal it.
Get to Work and Actually Finish things that say "DONE!"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants