CIP-???? | Affirmation Graph

[kieransimkin]

First draft of the Affirmation Graph - requesting CIP number to so that it can be referenced in the implementation that I'm currently working on and ongoing discussions about the process.

This PR has been re-created to provide a clean commit history.

Abstract:

We need a truly decentralized alternative to KYC for when we need to establish the authenticity of a wallet or make some judgement about its trustworthiness in a systematic and repeatable manner. This CIP defines a mechanism whereby any member of the community can publicly vouch for the authenticity of a wallet by submitting an "affirmation" transaction, it also provides a mechanism to revoke such an affirmation, if, for example a wallet becomes compromised, or its owner turns out to be a charlatan.
It is consequently possible to observe the current UTxO set and draw an "Affirmation Graph", a multidigraph representing the trust relationships between wallets - we can then use an algorithm to assign trust rankings and decide whether or not to trust an unknown wallet.

---

(rendered latest proposal version)

[rphair]

Marking Triage to introduce it at the next CIP meeting (https://hackmd.io/@cip-editors/100). Issues that might come up in initial review:

• the Specification is currently quite narrative and might be more easily generalised if it were written schematically;
• if the method currently derives from a single smart contract (forgive me if I am misreading it), acceptance as a Proposed CIP would depend on community agreement that other smart contracts could be independently written that are still compliant with this CIP.

Personally I think the idea of "one wallet, one vote" would play an important role in the Governance process: at the very least as an analytical tool.

[kieransimkin]

I have altered the specification so that it is generic and allows for independent third parties to write affirmation scripts that meet this specification. See 766e108

[Crypto2099]

Correct me if I'm wrong here @rphair but usually we ask that implementation examples (like the included Aiken scripts) should live in a separate repository under control of the author and merely be linked from the CIP itself? This allows the author much more latitude to update and change example scripts over time rather than requiring additional PRs against the CIP directory?

[rphair]

no @Crypto2099, that's not wrong & is actually a requirement of CIP-0001 (https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#1a-authors-open-a-pull-request).

As @kieransimkin has stated this is a "first draft" but perhaps after an initial community review of the material all together we would have to insist the code be moved into a separately maintainable repository (if not there already) & linked.

[kieransimkin]

Correct me if I'm wrong here @rphair but usually we ask that implementation examples (like the included Aiken scripts) should live in a separate repository

You're quite right, code duplication is never a good thing - I've removed the smart contract from this repository and instead linked to it at its original repository.

I've also done a lot of tidying throughout the CIP, improved the formatting, and added a diagram to the abstract.

This has resulted in rather a lot of individual small commits as I was testing how the markdown would render in Github. Is this large number of commits considered bad? (I understand they're used to generate automated changelogs?) - If this is undesirable I'm happy to rewrite the Git history so that they're all squashed into a single commit.

[rphair]

Is this large number of commits considered bad?

No, and generally it depends on an author's writing & editing style. In this case I think you wanted a public reference for the document ASAP (for community discussion) which has the side effect of bringing all those commits into the public eye. I think that is a good thing more than bad, because it exposes the document evolution - especially since you (as not all CIP authors do) are naming your commits something meaningful instead of update README.md for every one 😅

We also end up with big strings of commits from editors when recommended code changes have to be committed from the GitHub UI. Sometimes that can look really redundant and dumb, but again it's just a consequence of cooperative editing.

In either case there's no point folding the commits here because 1) the PR merge will do that with respect to the overall repository, and 2) the PR commit history is assumed to be verbose. The only time when you might want to post a comment around a long trail of commits is to say something like "done, ready for review again please?" or to digest the purpose of several commits exactly as you've done above. 😎

The only thing that destroys all this is the dreaded "force push" which wipes out any history of cooperative editing, makes both contributors and changes hard to trace, makes it impossible to tell whether posted issues have been resolved except by manual reading, etc. Some of our institutional CIPs are being worked on elsewhere and I've seen they've been careful about merging commits from their own repository to this one through local forks... very nice.

(I've gone into detail here to note these recommendations to add to the CIP Wiki at the next opportunity) cc @Crypto2099 @Ryun1 @perturbing

[Crypto2099]

Well said and agree with @rphair w.r.t. the commit trail, make as many commits as you need to, it does show evidence of progress and change over time

[rphair]

@kieransimkin we considered this as a candidate at the CIP meeting 2 days ago, with the following recommendations (mainly reiterating #938 (review)):

• The Specification is still narrative & was believed to be more easily followed & generalised to other implementations if a more schematic version could be provided.
• @Crypto2099 volunteered to review the smart contract presentation to validate (or recommend adjustments in favour of) a scope of third party implementations that would be necessary to consider this as a standard.

[kieransimkin]

• The Specification is still narrative & was believed to be more easily followed & generalised to other implementations if a more schematic version could be provided.

I guess I don't really understand what you're asking for with the word "schematic"? You want diagrams? I've rewritten it so that it precisely describes the process you must follow to register an affirmation and the criteria an affirmation contract must meet - how much more general can it get?

• @Crypto2099 volunteered to review the smart contract presentation to validate (or recommend adjustments in favour of) a scope of third party implementations that would be necessary to consider this as a standard.

Thank you - look forward to your review @Crypto2099

[rphair]

I guess I don't really understand what you're asking for with the word "schematic"? You want diagrams? I've rewritten it so that it precisely describes the process

@kieransimkin my apologies: I was passing along the feedback from the meeting (some of it from me) based on a previous reading of the document. I thought I had double-checked your Specification before the meeting but I guess I was wrong. What you updated 5 days ago looks excellent & is exactly what I had in mind... so consider this first point resolved as far as I'm concerned. 🙏

[kieransimkin]

In that case can I have proposed status and a cip number please? :)

[rphair]

As soon as the contracts are confirmed according to #938 (comment) (even if by another editor), if OK with other editors I'll see if we can assign a number before the next CIP meeting. As a failsafe I've posted this for Review @ next meeting to make sure we can confirm this as a "candidate" (i.e. a CIP number) no later than this date: https://hackmd.io/@cip-editors/101

p.s. @kieransimkin if none of the other editors have found a problem with the generality of the smart contract(s) by (or in) that meeting, I'll recommend that we consider that matter at least temporarily resolved & assign a number then (if not already) - p.s. also pending resolution of concerns expressed in #938 (review).

[perturbing]

This CIP presents an innovative approach to building decentralized trust relationships through the Affirmation Graph. While the proposal has potential as a complementary tool for assessing trust, it does not provide a robust alternative to KYC or a reliable foundation for governance voting. The probabilistic nature of the system, coupled with concerns about algorithm manipulation and overstatements of its capabilities, limits its suitability for critical applications like identity verification or democratic voting. Clearer framing of its goals and limitations would enhance the CIP's credibility and usability.

[perturbing]

Why not use transactional metadata? It is an old discussion, but good to ask again and again, why is it needed to have the data in the active UTxO set?

[kieransimkin]

Mainly so that you aren't required to run a chain indexer in order to have any visibility on the graph. The idea is that trust ratings would be presented in wallets, and the wallets themselves would generate those ratings directly from the UTxO set.
Also, conceptually, a UTxO represents an affirmation quite well - it's always pending and can be revoked at any time.

I have made an effort to minimize the size of the datum - that's why the included smart contract is written to allow two different datum specs - the default and most simple one contains only the public key hash of the person giving the affirmation - this is the datum that is expected to be used in 99% of cases.

Unfortunately the script does also require minting a kinda pointless token - but this is just a necessary trick to get Cardano to perform validation upon creation of the affirmation UTxO, since Cardano does not otherwise perform validation upon creating a UTxO - I wonder, is there a CIP for that?

[rphair]

the script does also require minting a kinda pointless token - but this is just a necessary trick to get Cardano to perform validation upon creation of the affirmation UTxO, since Cardano does not otherwise perform validation upon creating a UTxO - I wonder, is there a CIP for that?

@fallen-icarus this sounds familiar & I think you've covered that realm... would you recommend any approach either from a merged or candidate CIP?

[fallen-icarus]

the script does also require minting a kinda pointless token - but this is just a necessary trick to get Cardano to perform validation upon creation of the affirmation UTxO, since Cardano does not otherwise perform validation upon creating a UTxO - I wonder, is there a CIP for that?

I've only briefly looked at this CIP so apologies if I am misunderstanding something.

If you don't care about the token, then perhaps the "withdraw 0 ADA" trick would be better. You would use a staking script to validate the new affirmation UTxO; the script will be executed as long as the amount of ada withdrawn from its staking address is >= 0. CIP-112 was created to add a dedicated "observe script" type which would be cleaner than even the "withdraw 0 ADA" trick.

Another possibility is to use the token itself as a stamp of validity: the token can only be stored in the UTxO if the UTxO is properly constructed. Then the indexers can just filter the current UTxO set by those that contain these tokens. Off-chain indexers make this very easy; they usually have dedicated "Asset UTxOs" endpoints (maestro, koios). This would provide more secure indexing than just using the affirmation address since it is possible to create invalid UTxOs at the address without executing the minting policy or staking script (ie, addresses can't deny UTxOs). It is quite old but the beacon token CIP explains how to do this in a trustless setting; but if you think you can trust the UTxO creator, an adaptation of CIP-68 may also work.

[perturbing]

The abstract sets an ambitious goal by suggesting that this CIP provides a "truly decentralized alternative to KYC." However, the solution proposed—an Affirmation Graph—is probabilistic and does not provide guarantees about a wallet's authenticity or trustworthiness. While the system introduces a novel approach to building decentralized trust relationships, it falls short of delivering the full equivalence of KYC.

Two specific concerns arise from this:

Overstating the Solution's Capabilities: The current wording creates the impression that the Affirmation Graph is a comprehensive replacement for KYC. This could lead to a false sense of security for users who might overestimate its reliability.

Unclear Goal Alignment: If the system inherently cannot guarantee trust, what is the purpose of framing it as an alternative to KYC? A more accurate framing might describe it as a tool for probabilistic trust evaluation rather than a replacement for centralized identity verification.

A possible rephrasing of the opening could be:

"This CIP defines a decentralized mechanism to establish probabilistic trust relationships between wallets, providing a step toward alternatives to centralized KYC mechanisms."

This revision would better align with the proposal's actual capabilities while setting realistic expectations for its use. Additionally, it might be helpful to include a disclaimer in the abstract to caution readers about the limitations of probabilistic trust mechanisms, ensuring transparency and reducing the risk of misuse.

[kieransimkin]

The abstract sets an ambitious goal by suggesting that this CIP provides a "truly decentralized alternative to KYC." However, the solution proposed—an Affirmation Graph—is probabilistic and does not provide guarantees about a wallet's authenticity or trustworthiness. While the system introduces a novel approach to building decentralized trust relationships, it falls short of delivering the full equivalence of KYC.

This is not strictly true:-
I will be setting up a service which performs traditional KYC and grants you an affirmation in return. If you wanted, you could only trust affirmations from this stake address, and then you'd have a direct implementation of traditional KYC, within the Affirmation Graph context, so that will provide guarantees about a wallet's authenticity.

Two specific concerns arise from this:

Overstating the Solution's Capabilities: The current wording creates the impression that the Affirmation Graph is a comprehensive replacement for KYC. This could lead to a false sense of security for users who might overestimate its reliability.

Always better to underpromise and overdeliver, I'll take that point.

Unclear Goal Alignment: If the system inherently cannot guarantee trust, what is the purpose of framing it as an alternative to KYC? A more accurate framing might describe it as a tool for probabilistic trust evaluation rather than a replacement for centralized identity verification.

In my mind, it is a direct alternative to KYC, but founded on the principle of decentralization - it's directly analogous - instead of relying on a central authority, you're relying on the "hive mind".

A possible rephrasing of the opening could be:

"This CIP defines a decentralized mechanism to establish probabilistic trust relationships between wallets, providing a step toward alternatives to centralized KYC mechanisms."

This revision would better align with the proposal's actual capabilities while setting realistic expectations for its use. Additionally, it might be helpful to include a disclaimer in the abstract to caution readers about the limitations of probabilistic trust mechanisms, ensuring transparency and reducing the risk of misuse.

I agree it's probably sensible to add some note of caution, as with any system of trust really, it's only as reliable as its participants.

[perturbing]

The statement about using an algorithm to assign trust rankings introduces a potential vulnerability. If the specific algorithm used to assign trust values to wallets becomes widely known, it could be exploited or “gamed” by malicious actors. This could lead to manipulated trust rankings, undermining the reliability of the system.

This issue becomes particularly problematic if users develop a false sense of security, assuming that the trust rankings are inherently reliable or immune to manipulation.

[kieransimkin]

This is why the specification and the associated toolchain leave the actual selection of algorithm down to the end user, and it will vary depending on different use-cases. Some users might choose to only trust wallets that have been affirmed by a centralized KYC provider - in this case the security guarantee is equal to that of the KYC provider. Others might choose to trust only people affirmed certain select individuals, but in this instance you would be assuming those individuals had not been compromised.

I will add some caveats to explain the potential pitfalls around this.

[perturbing]

The claim that this CIP could "drastically reduce the risk of fraud and accidental loss of funds" feels overstated. While it makes trust evaluations more systematic and repeatable, it does not eliminate risks like system manipulation or false trust. A more balanced phrasing might highlight that it complements manual diligence rather than fully replacing it.

Something like

"This CIP proposes a decentralized mechanism for assessing wallet trustworthiness in a systematic and repeatable way, aiming to reduce the effort and inconsistencies of manual evaluations. While it does not eliminate risk entirely, it provides a new tool to complement existing approaches to fraud prevention."

[kieransimkin]

I'll take that wording :) Thanks.

[perturbing]

While I agree with the sentiment of the statement, this CIP does not actually propose a solution for providing such an ID, making the inclusion of this line somewhat misleading.

[kieransimkin]

Perhaps I should explicitly state that we're basically treating stake keys as DiDs here, and a stake key with a high trust rating is a form of ID in itself. I do understand the potential for confusion here though so I will clarify.

[perturbing]

The claim of a "simple, truly decentralized mechanism for identity verification and trust" feels overstated. Based on the issues raised in my earlier comments, this CIP provides a mechanism for probabilistic trust relationships, which is not equivalent to robust identity verification. A more accurate phrasing might clarify that it offers a decentralized tool for assessing trust rather than verifying identity outright.

[kieransimkin]

It does also support robust identity verification in the form of affirmations by KYC providers. In fact it makes these KYC verifications portable so that you only need to do KYC once and it's portable to any dApp on Cardano.
That said, I take your point about overpromising, and will scale back some of the grand claims ;)

[perturbing]

While I understand the desire for an alternative to stake-weighted voting, I believe this solution is not suited as a foundation for governance voting. Given the outlined security concerns and the probabilistic nature of this system, it can only serve as a complementary tool, not a reliable basis for ensuring fair and secure voting.

[rphair]

@perturbing does this also mean that malicious user(s) could exploit such a system to influence the outcome? I read your comments for such a statement & perhaps it's implicit in what you wrote, but if true I would prefer to also record this literally.

I had made some prior comments (here and on the Cardano Forum) suggesting this tool might be usable for analytical purposes even if votes were not conducted with it. But any procedure for exploit would invalidate (or require strict disclaimers on) even this use case: since the more valuable the "affirmation" the more likely that people would try to game the outcome.

[perturbing]

Well, it depends on how the algorithms are defined and who uses what. But yes, I think this can approach can be “gamed” or influenced in an unintended way.

I do not think the idea is invalid because of this, just that it should be apparent what such a tool brings (and what not).

IMO, this is definitely not a tool for governance voting.

[kieransimkin]

The devil is really in the detail of how you interpret the graph - in the most simple case where you're basically just adding 1 to the trust score for every affirmation that a wallet has - there's definite potential for abuse with that. However, in a lot of cases, that might be "good enough".
The real power comes when you start weighting affirmations based on various criteria. As mentioned, you could only give any weight at all to affirmations from centralized KYC services - this enables portable KYC, so you only have to do KYC once on Cardano and then all dApps can see that you've done it. I will probably write a further specification around these centralized KYC->Affirmation services, as they will attach metadata to the affirmation enabling the KYC to be traced if necessary.

The exciting bit for me is when you start building complex algorithms for interpreting the graph - the Affirmation Graph indexer that I'm building gives quite a lot of information that can be used to inform these algorithms. For example, the date when every affirmation occurred, the date of a each wallet's first ever transaction (of any kind), smart contracts that wallet has interacted with (and frequency), native tokens held by that wallet etc. So this would enable you to implement certain safeguards - say, de-weighting affirmations from any newly created wallet. You can also use graph theory to detect new clusters, or isolated clusters that are not strongly interwoven with the rest of the graph. You could also detect unusual behaviour that might result from a compromised wallet - for example if a wallet suddenly starts issuing lots of affirmations outside their own local cluster, and to relatively new or untrusted wallets.

Members of the various factional communities on Cardano (mostly centred around NFT projects) will be able to bias their judgements in favour of members of their own community - giving their affirmations a higher weight. OR you could choose to ignore the opinion of anyone who holds a particular meme coin that you may dislike.

The power is in allowing people to design their own graph interpretation algorithm - I may even create a visual algorithm-builder, such that even non-technical users will be able to design and customize their own algorithm, and encode their own personal biases within it.

I have also thought about using machine learning to further augment the safeguards - once the graph is established and we have some examples of good and bad actors, it might make sense to train an AI to detect bad actors. It might even be capable of predicting rug pulls before they happen. However, I'm personally philosophically a bit wary of bringing AI into what is basically a social experiment on trust - it could get dystopian pretty quickly. But once the graph is there, someone is bound to use AI to interpret it - opening that Pandora's box is inevitable.

I take on board the points about scaling back some of the claims, and adding caveats around potential pitfalls, and I will redraft the CIP with this in mind. However, it is still my belief that this system can and will become equally, if not more trustworthy then traditional KYC. After all, you can buy a fake identity that will pass KYC on the darknet for a few hundred dollars - circumventing KYC is trivial to someone who knows what they're doing - it's one big single-point-of-failure. What would not be trivial, would be convincing a significant number of respected and established community members to literally stake some Ada on me as a person - sure, people can often be bought, but if it becomes apparent that a community member is consistently giving dodgy affirmations, that community member's trust rating can be expected to take a nose-dive.

Or put more simply - I trust the community more than I trust the government - within the scheme I'm proposing, the government effectively becomes another member of the community, and it's up to the individual to decide how much weight they place on the government, versus their close circle, versus any factions they're a member of, versus the opinion of the wider community.

The first step is building out the graph - ie, allowing people to give each other affirmations (I am very nearly ready to launch this). Initially I will not be deriving any trust ratings from it - I'm simply going to allow people to view their place on a network diagram. I anticipate that it will take some time for the graph to become established before it will be useful for actually determining trust scores, and there is no rush to do that - I won't start assigning trust scores until the graph is rich enough to contain useful information - it's better to do nothing than get it wrong!

[kieransimkin]

Thanks for all the great feedback @perturbing - I will redraft the CIP and update this PR when it's done. That will probably also coincide with an actual working implementation at https://clg.wtf which I'm just putting the finishing touches to now.