Relying Party (RP)

DeFi lending platforms act as Relying Parties by requiring proof of collateral ownership or creditworthiness before issuing a loan. They rely on on-chain attestations (like tokenized real-world assets) or zero-knowledge proofs of financial history to assess risk without exposing private data.

• Example: Aave requiring a zkKYC proof to access permissioned liquidity pools.
• Mechanism: The user's wallet presents a verifiable credential from a trusted issuer; the smart contract verifies its cryptographic signature.

DAOs use RPs to gate membership, voting rights, and treasury access. They rely on proofs of identity, reputation, or skill to create sybil-resistant communities.

• Example: A developer DAO requiring a Gitcoin Passport (a collection of attestations) to join.
• Example: A grant committee verifying Proof-of-Attendance Protocol (POAP) NFTs to weight community voting power.

Cross-chain messaging protocols and bridges act as RPs by verifying state proofs from another blockchain before executing actions. They rely on light client proofs or validator set signatures to trustlessly confirm events.

• Example: A Layer 2 bridge verifying a Merkle proof that funds are locked on Ethereum Mainnet before minting wrapped assets.
• Core Function: The bridge's smart contract is the RP, consuming and validating the proof's cryptographic validity.

Corporations and regulators act as RPs in enterprise blockchain networks to verify provenance and compliance. They rely on tamper-evident logs and digital certificates issued at each supply chain step.

• Example: An automotive manufacturer verifying proof of origin for conflict-free minerals.
• Example: A customs agency checking verifiable credentials for trade document authenticity, enabling faster clearance.

Social graphs and game economies rely on proofs of identity, achievement, or social connection to customize experiences and prevent fraud.

• Example: A web3 social platform using ERC-6551 token-bound accounts to let users prove NFT ownership for exclusive groups.
• Example: A game using verifiable credentials for player skill level or completed quests to enable cross-game interoperability.

Smart locks, vehicles, and IoT devices can be programmed as RPs, granting access based on cryptographic proofs instead of physical keys or centralized databases.

• Example: A car door unlocking via a digital key credential in the owner's mobile wallet.
• Architecture: The device (the RP) contains a verifier that checks the credential's signature and revocation status before triggering an action.

An RP must authenticate users without a central authority, creating the Verifier's Dilemma. To prevent Sybil attacks, RPs rely on:

• Proof-of-Personhood systems (e.g., Worldcoin, BrightID).
• Staked Identity where a financial bond backs the credential.
• Social Graph Analysis to establish unique human identity. Failure to implement robust Sybil resistance allows a single entity to masquerade as many, corrupting governance and reward systems.

A credential's validity can change. RPs must check its revocation status to prevent accepting compromised claims. Common mechanisms include:

• Revocation Registries: The issuer maintains a cryptographically verifiable list of revoked credential IDs.
• Status Lists: A signed, timestamped list (e.g., W3C Status List 2021) the RP fetches and verifies.
• On-Chain Revocation: Using a smart contract as an immutable revocation ledger. Without active status checks, an RP trusts stale data.

RPs should request only the minimum necessary data via Selective Disclosure. Zero-Knowledge Proofs (ZKPs) enable this by allowing a user to prove a claim (e.g., 'I am over 21') without revealing the underlying data (their birth date). This:

• Minimizes Data Exposure for user privacy.
• Reduces RP Liability as they store less sensitive data.
• Uses cryptographic proofs (e.g., zk-SNARKs, BBS+) verified against the issuer's public key.

For compliance and dispute resolution, RPs must maintain cryptographic audit trails. Every verification creates a verifiable record including:

• The presented verifiable credential/proof.
• The RP's verification timestamp and process.
• The cryptographic signature of the verification result. This provides non-repudiation, meaning a user cannot falsely deny having presented the credential, and the RP cannot deny the verification outcome.

An RP cannot blindly trust all issuers. It consults a Trust Registry—a managed list of authorized issuers and the schema of credentials it accepts. This defines the RP's trust framework. Key functions:

• Issuer Onboarding/Offboarding: Dynamically updating trusted entities.
• Schema Validation: Ensuring credentials conform to expected data structures.
• Decentralized Identifiers (DIDs): Using DIDs as the root of trust for issuer keys, enabling resolver lookups.

The RP's own cryptographic keys are a critical attack vector. Secure key management involves:

• Hardware Security Modules (HSMs) for signing key protection.
• Regular Key Rotation policies to limit exposure from a potential breach.
• Decentralized Key Management using distributed custody solutions. Compromise of the RP's signing key allows an attacker to forge verification receipts or corrupt the trust registry.