RFC for DRAFT Bounty xxB-2025-00`TODO`: xx Network Wallet on-chain identity fixes and improvements

General
1

Bounty xxB-2025-00TODO: xx Network Wallet on-chain identity fixes and improvements

Overview

This bounty rewards developers for implementing improvements to xx Network Wallet’s on-chain identity functionality to update and modernize code for existing and new use cases.

Total Prize: ????? xx (~$?,000 USD)

Motivation

The identity module of Polkadot SDK in xx Network wallet gives the owner the ability to link their wallet to various identities associated with the wallet.

Although on-chain identity on xx Network hasn’t been promoted or encouraged, it has been adopted by validators, Council members and others which demonstrates its inherent usefulness.

At the same time, it is not used to its full potential. For example:

  • Although almost all validators are active in the xx Network Discord, the field is dysfunctional and disables voluntary linking of validator or other Discord member wallet with Discord ID
  • No 3rd party registrars compatible with Substrate chains have been engaged to provide services to xx chain community, although they have existed for years

Current and future use cases

Demand for on-chain identity information would likely be stronger if the module was up to date and better tailored for current and future xx Network-related uses.

For example, Discord remains popular among xx Network validator and holder community, but no application can use it because currently the official wallet supports only old-style Discord IDs (someone#1234), while new Discord names cannot be set due to an outdated input validation in the xx Network wallet. Another example is ENS integration that was briefly demonstrated in Phonenixx (beta) and at the time well accepted, but is currently not available in other applications or the official xx Network wallet.

Lastly, some networks and applications have changed names (Twitter, Riot), new ones have emerged (BlueSky) and there are new use cases and integrations that we could open up. PolkadotSDK’s on-chain identity module supports many fields (100), so prudent expansion of current features is both safe and desirable.

Compliance

Another growing need for better on-chain information is mandatory compliance with various regulations in different jurisdictions.

This is not something new or something that would be “pushed” on the community in the future: the Foundation already performs KYC/AML checks on all bounty and grant recipients above certain limit, for example, because the law requires that in such payments identities of recipients (address owners) be checked.

The difference is these checks are currently performed manually which is time-consuming and hence costly. It is also less secure because rather than checking for an on-chain proof of identity (for example), this information is sent via less secure communication channels such as email. The third problem is that when identity checks are done by a “trusted” person (such as someone from the community), it is unlikely to result in privacy violations, but at the same time any P2P identity validation becomes difficult or impossible without there being a trusted independent registry or other readily available on-chain method.

Additionally, in late 2024 xx Network has increased the number of grants and bounties and this is expected to continue in 2025. That means increased compliance-related workload is expected. Another reason for increased focus on compliance is that other DAOs have already faced issues related to KYC/AML of not only grant and bounty recipients, but also various suppliers, Council members and more. It is therefore possible that the Council’s KYC/AML workload increases manifold in 2025.

Last but not least, some jurisdictions encourage or require identification for non-custodial wallets. Having a DID attached to one’s wallet may make holding XX coin easier in terms of tax-reporting burden. There are additional use cases where having an on-chain DID benefits applications (i.e. IoT) and users in terms of compliance.

Expected changes and outcomes

The following groups of changes in the module and related documentation are proposed:

  • Fix outdated entry validation rules
  • Update outdated network/application names
  • Add new social networks and applications
  • Add new fields for current and future use cases

With these changes in place, it is expected that existing and new external IDs become usable (Discord, BlueSky), community engagement becomes easier, compliance costs don’t grow proportionately with the number of payments, bounties or grants, and P2P trust increases due to identities verified or attested on linked platforms (see (1) in Footnotes).

Two “generic” IDs (ENS and W3N) are proposed with the purpose of expanding use cases, but also preventing UI bloat: these can link to other identifiers on their own, so the user may avoid having to provide a Web site address in on-chain module when the same can be obtained from their ENS record, for example. The same applies to W3N. While ENS lives on the Ethereum blockchain, KILT uses a Substrate chain making it more convenient for certain use cases and application integrations. For example, the same passphrase can be used to unlock one’s W3N wallet, XX wallet and any other linked wallet or application from one of Substrate chains.

Non-objectives

On-chain identity remains optional for all cases where the Council or the Foundation does not require KYC/AML procedures. Where such procedures be required, the Council or Foundation may choose to ask the wallet owner to setup one of supported identities (if any be supported) and thereby eliminate the need to send documents to a “trusted” person.

Bounty or grant payments for users below the KYC/AML limit remain unaffected. The same applies to all other wallet owners (validators, nominators, and other wallet users) who can continue using (or not using) on-chain identity the same way as they have before.

Breakdown:

  • Modal updates and improvements: ? xx
    • “Set on-chain identity” - modal modifications and additions
    • Display complete on-chain identity modal
  • API examples (JavaScript): ? xx
    • Update wallet on-chain ID
    • Query wallet on-chain ID
  • Documentation ? xx
    • Wallet
    • Documentation (JS API)

Requirements

Eligibility

  • Participants must complete KYC verification
  • Participants from OFAC-sanctioned countries are not eligible
  • Multiple contributors may collaborate on submissions
  • Existing xx network contractors are eligible as long as the trustee is a different person

Technical Requirements

NOTE: fields longer than the maximum possible on xx Chain may be dropped or limited to chain maximum.

  • Set identity modal

    • Disallow submissions that would end up truncated
    • Discord: add another valid regex match to accommodate new Discord usernames from 2024 - reference
    • Web: allow longer URLs (potentially up to the maximum if there are no chain-related concerns) -reference.
    • Twitter: replace twitter with x (twitter)
      • @ + x id
    • Riot: replace with matrix (or matrix id)
    • (new) Haven
      • At least 103 bytes, maybe more if this field could grow - reference
      • If field length is limited and the chain canot accept 103 bytes, allow and document the maximum
    • (new) BlueSky
    • (new) ENS
      • Min and max length: >=3 && <=30 bytes ([subdomain.] + tld + [.eth|.box], e.g. th_is.sub.domain.eth)
      • Document reason for on-chain character limitation despite .ens and .box supporting longer names
    • (new) Web3 name (w3n: prefix as part of raw string)
      • DID implementation by KILT, for optional two-way mapping between a wallet and DID or simply for wallet aliasing similar to ENS names, built in standards-compliant fashion
      • Example: w3n:jonsmith. (@w3n is the default suffix which can be ignored as apps that deal with W3Ns add it on their own)

  • Show identity card

    • Show all details in a card
    • (new) Shorten displayed values as necessary for the screen
    • (new) Add “copy” icon after each field (or at least after those with shortened values to enable copying on screens which cannot accommodate long TLDs, IDs, usernames, handles, etc.)

Submission Requirements

  • Source code must be:

    • Open source (same license as xxDK)
    • Submitted via merge request to appropriate repository
    • Well-documented
    • Passing all tests
    • Following project coding standards

  • Documentation must include:

    • API documentation
    • Workflow and screenshots for setting and viewing on-chain identity
    • Build/installation instructions (if different from current)

Judging Criteria

Submissions will be evaluated on:

  • Completeness of implementation
  • Code quality and maintainability
  • Documentation quality
  • Test coverage
  • Performance

Timeline

  • Submissions accepted until completed or program ends
  • Reviews will occur within 2 weeks of submission
  • Prizes paid within 30 days of approval

Payment Terms

  • Prizes paid in XX tokens
  • Multiple submissions may split prize pool
  • Major awards (>50,000 XX) subject to 6-12 month linear vesting
  • All payments subject to KYC approval
  • We may make partial payments at our discretion
  • Payments may be locked in a linear vesting schedule for up to 1 year

Contact

Submit questions and proposals through:

  • xx network repository issues
  • xx network forum
  • xx network Discord developer channel (#developers)

Please respond in the forum if you are pursuing this grant.

Legal

  • xx network reserves right to modify bounty terms
  • All submissions must comply with applicable laws
  • Participants retain rights to submitted code under project license
  • xx network not responsible for lost or invalid submissions

Reference

Footnotes

(1)

You can also link some of your credentials publicly, adding an extra layer of verification to your identity.

License: CC BY-NC-SA 4.0

I started working on this last year and then stopped because:

  • the vocal minority seems determined to run the network into the ground and has been consistently opposed to ideas like this one
  • the silent majority is MIA, so there’s no point in doing anything for them

Still, because the bulk of the work in creating this draft bounty was done before I stopped working on it, today I decided to put an extra hour into this and share it here in the case anyone wants to continue this initiative.

This area isn’t trivial and changes happen every so often. Although I tried to scope this out in a way that gives the most “bang for the buck” while not taking a direction that diverges from where (I think) Polkadot was going, maybe it is too broad, too narrow or even directionally wrong. But I’m not going to refine it with insights gained this year because of the reasons mentioned above. It is provided as-is and if someone wants to spin a completely different version or change whatever needs to be changed, feel free!

2 Likes