Skip to main content

Run a Validation Process to Obtain a Permission

This method is used by any applicant who wants to join an ecosystem’s credential schema when self‑creation is not allowed (schema mode ≠ OPEN), or when a validator charges validation_fees (e.g., some Holder flows).

Refer to the learn section for background on validation processes.

When do you need a validation process?​

  • If schema’s issuer_perm_management_mode = ECOSYSTEM → apply under the root (ECOSYSTEM) permission of that schema.
  • If schema’s issuer_perm_management_mode = GRANTOR_VALIDATION → apply under an ISSUER_GRANTOR permission.
  • If schema’s verifier_perm_management_mode = ECOSYSTEM → apply under the root (ECOSYSTEM) permission.
  • If schema’s verifier_perm_management_mode = GRANTOR_VALIDATION → apply under a VERIFIER_GRANTOR permission.
  • Holder: if the selected Issuer charges validation_fees, the Holder must run a validation process under that Issuer.

In OPEN mode the applicant self‑creates the permission and does not run a validation process.

What the chain does​

  • Creates a permission entry with vp_state = PENDING.
  • Locks / accounts for any trust deposit and fees as defined by the ecosystem and validator settings.
  • The permission becomes usable only after the validator sets it to VALIDATED.

Prerequisites​

  • You know the permission type you’re applying for (issuer, verifier, issuer‑grantor, verifier‑grantor, holder).
  • You have the validator permission ID to apply under (root / grantor / issuer).
  • You have sufficient balance to cover gas (and any deposit/fees computed by policy).

To locate validator permissions:

veranad q perm list-permissions --node $NODE_RPC --output json | jq

Message Parameters​

NameDescriptionMandatory
permission-typeOne of: issuer, verifier, issuer-grantor, verifier-grantor, holderyes
validator-perm-idThe permission ID of the validator you apply under (root/grantor/issuer depending on role)yes
countryApplicant’s ISO 3166‑1 alpha‑2 country codeyes

Post the Message​

Usage​

veranad tx perm start-perm-vp <permission-type> <validator-perm-id> <country> \
  --from <user> --chain-id <chain-id> --keyring-backend test --fees <amount> --gas auto --node $NODE_RPC

Examples​

1) Apply as ISSUER_GRANTOR under the root (ECOSYSTEM) validator

VALIDATOR_PERM_ID=2   # ecosystem root perm for schema 5
veranad tx perm start-perm-vp issuer-grantor $VALIDATOR_PERM_ID US \
  --from $USER_ACC --chain-id $CHAIN_ID --keyring-backend test --fees 600000uvna --gas auto --node $NODE_RPC

2) Apply as ISSUER under the ISSUER_GRANTOR

VALIDATOR_PERM_ID=2   # issuer-grantor perm id
veranad tx perm start-perm-vp issuer $VALIDATOR_PERM_ID US \
  --from $USER_ACC --chain-id $CHAIN_ID --keyring-backend test --fees 600000uvna --gas auto --node $NODE_RPC

3) Apply as VERIFIER under a VERIFIER_GRANTOR

VALIDATOR_PERM_ID=41  # verifier-grantor perm id
veranad tx perm start-perm-vp verifier $VALIDATOR_PERM_ID GB \
  --from $USER_ACC --chain-id $CHAIN_ID --keyring-backend test --fees 600000uvna --gas auto --node $NODE_RPC

4) Holder applies under an ISSUER that charges validation fees

ISSUER_PERM_ID=55
veranad tx perm start-perm-vp holder $ISSUER_PERM_ID FR \
  --from $USER_ACC --chain-id $CHAIN_ID --keyring-backend test --fees 600000uvna --gas auto --node $NODE_RPC

Verify the request was recorded​

Filter by your account and look for a newly created permission with vp_state = "VALIDATION_STATE_PENDING":

veranad q perm list-permissions --node $NODE_RPC --output json \
| jq '.permissions[] | select(.grantee == "'$USER_ACC_LIT'")'

(You can also inspect the tx hash printed by the CLI to retrieve the created ID.)

Off‑chain interaction​

After submitting the request, contact the validator’s DID (e.g., via DIDComm or the channel specified in the EGF) to provide evidence and complete checks (KYC/compliance, capability proofs, etc.).

When satisfied, the validator must call Set Permission to Validated to activate your permission:

Flow Diagram​

plantuml

  • End of file.