5 releases (2 stable)

3.3.0 Jan 5, 2023
3.1.4 Dec 1, 2022
0.2.0 Jul 27, 2021
0.1.1 May 1, 2021
0.1.0 May 1, 2021
Download history 109/week @ 2024-06-30 133/week @ 2024-07-07 293/week @ 2024-07-14 154/week @ 2024-07-21 197/week @ 2024-07-28 168/week @ 2024-08-04 182/week @ 2024-08-11 179/week @ 2024-08-18 211/week @ 2024-08-25 196/week @ 2024-09-01 216/week @ 2024-09-08 177/week @ 2024-09-15 223/week @ 2024-09-22 171/week @ 2024-09-29 96/week @ 2024-10-06 145/week @ 2024-10-13

660 downloads per month

MIT license

73KB
1.5K SLoC

did:sol Program

The anchor-based program of did:sol on Solana.

Creating DIDs

Any Solana public key can be a DID. This means that if you have a public key abc, then that key corresponds to the decentralized identifier did:sol:abc.

This DID is called a generative DID, because it is generated from a public key, and has no other information associated with it.

Generative DIDs have one authority, which is the public key itself (abc in this case).

Adding information to DIDs

In order to add more authorities, or any other information to the DID, it must be initialised on chain, using the initialize instruction.

Once a DID is initialized, other keys can be added to it using the add_verification_method instruction.

DID Accounts

The information for a DID is stored on a DID Account, a PDA that is derived from the DID identifier.

In order to derive the PDA for any DID, the following function is used:

use sol_did::integrations::derive_did_account;

let (did_account, bump) = derive_did_account(key.to_bytes())

Where key is the identifier of the DID (abc in the above case)

In order to reduce the amount of calculations that are needed to derive the DID account, you can pass the bump value as a parameter:

use sol_did::integrations::derive_did_account_with_bump;

let did_account = derive_did_account_with_bump(key.to_bytes(), bump)?;

Note, in this case, the function returns a Result, in case the bump value is incorrect.

Checking if a key is an authority on a DID

In order to use DIDs in your program, add the DID account to your instruction accounts list.

The DID account is the that stores the DID information. Note: this can be generative (see above).

To check if a key is an authority of a DID, use the is_authority instruction.

use sol_did::integrations::is_authority;

let signer_owns_did = is_authority(
    &did_account,
    None,
    &[],
    &signer.to_bytes(),
    None,
    None
);

This function works in the generative and non-generative case. In the generative case, the did_account must be owned by the system program.

Controller relationship

One DID can be a controller of another DID.

If a key a is an authority on did:sol:abc, and did:sol:abc is a controller of did:sol:def then the following is_authority relationship is true:

use sol_did::integrations::is_authority;

let signer_owns_did = is_authority(
    &abc_account,
    None,
    &[(def_account_info, def)],
    &abc.to_bytes(),
    None,
    None
);

Instructions

initialize

Arguments:

  • size: u32

Accounts:

  • didData isMut
  • authority isSigner, isMut
  • payer isSigner, isMut
  • systemProgram

resize

Arguments:

  • size:u32
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner
  • payer isSigner, isMut
  • systemProgram

close

Arguments:

  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner
  • destination isMut
  • systemProgram

add_verification_method

Arguments:

  • verificationMethod:VerificationMethod
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

remove_verification_method

Arguments:

  • fragment:string
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

add_service

Arguments:

  • service:Service
  • allowOverwrite:bool
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

remove_service

Arguments:

  • fragment:string
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

set_vm_flags

Arguments:

  • flagsVm:UpdateFlagsVerificationMethod
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

set_controllers

Arguments:

  • setControllersArg:SetControllersArg
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

update

Arguments:

  • updateArg:UpdateArg
  • ethSignature:Option<Secp256k1RawSignature>

Accounts:

  • didData isMut
  • authority isSigner

migrate

Arguments:

Accounts:

  • didData isMut
  • authority
  • payer isSigner, isMut
  • legacyDidData
  • systemProgram

Deployments

APR Reference

  • did:sol program on APR

Dependencies

~20–29MB
~503K SLoC