Multi-Credential Proofs & Delegation

Certain verification scenarios in the agent economy require proving claims that span multiple distinct credentials issued by different authorities. For instance, an AI agent managing a decentralized finance protocol might need to verify that a user is both a resident of a specific jurisdiction (from an Identity Credential) and meets an income threshold (from a Financial Credential). Furthermore, users frequently interact across multiple blockchain networks or platforms using different wallet addresses, requiring mechanisms to delegate their verified status without re-verifying.

These two capabilities, multi-credential proofs and delegated proofs, are presented together because they address complementary dimensions of the same fundamental challenge: how a single verified identity operates at scale across complex, multi-chain agent ecosystems. Multi-credential proofs solve the breadth problem (proving claims across many credentials in one interaction), while delegated proofs solve the reach problem (extending a verified identity across many addresses and agents without repeating the verification process). In practice, an AI agent that needs to verify a complex user profile will often use both capabilities in a single session.

---

Multi-Credential Proofs (Linked Queries)

To handle complex, multi-credential requirements efficiently, zkMe supports the LinkedMultiQuery10 circuit architecture.

The LinkedMultiQuery10 Architecture

The LinkedMultiQuery10 circuit allows a Holder to generate a single, unified zero-knowledge proof that aggregates up to 10 different queries across multiple credentials.

1. Batch Processing: In older protocol versions, if an agent needed to verify 5 different data points from 3 different credentials, it required the generation of 5 separate zero-knowledge proofs and multiple on-chain submissions. The LinkedMultiQuery system consolidates this into a single proof and a single on-chain transaction. The frontend SDK processes an array of queries and generates one proof that validates all conditions simultaneously.

2. Circuit Validation: The circuit verifies multiple field-based predicate requests in parallel. It outputs specific public signals to represent the result of the batch operation, including operatorOutput[10] (for any selectively disclosed fields within the batch) and circuitQueryHash[10] (for gas-efficient on-chain verification of each query condition).

3. Link Consistency: A critical security feature of this architecture is the linkID (mapped to a groupID in the request configuration). When processing multiple queries, the system enforces that all proofs within the batch share the exact same groupID. This cryptographically guarantees that the disparate pieces of information belong to the exact same user and the same underlying identity, preventing a malicious user from mixing and matching credentials from different identities to pass a complex policy check.

Query Example

The following configuration demonstrates a LinkedMultiQuery10 request that verifies two conditions in a single proof: the user is over 18 years old and holds a nationality matching a specific country code.

const linkedQuery = {
  claimPathKey: [ageFieldPath, nationalityFieldPath],
  operator: [3, 1],       // GT (greater than), EQ (equal)
  value: [[18, ...zeros], [840, ...zeros]],  // age > 18, nationality == 840 (US)
  queryHash: [ageQueryHash, nationalityQueryHash],
  circuitIds: ["linkedMultiQuery10"],
  groupID: 1,
  verifierID: 1
};

The key difference from the older workflow is immediately visible: instead of generating separate proofs for each condition and submitting them individually, the entire set of queries is packaged into a single request with a shared groupID.

Complementary Security Design

It is important to understand that the LinkedMultiQuery10 circuit is optimized specifically for efficiency (batching) and data validation. By design, it does not handle the core cryptographic security checks of the credential itself. Its public signals are limited to linkID, merklized, operatorOutput[10], and circuitQueryHash[10].

Therefore, the LinkedMultiQuery circuit is designed to be used in a complementary pattern with the core credential verification circuit.

Responsibility	LinkedMultiQuery10	Core Credential Verification Circuit
Batch queries and multi-field validation	Yes	No (single query per proof)
Selective disclosure across multiple fields	Yes	Single field only
Link consistency (linkID / groupID)	Yes	Yes
User identity verification (userID)	No	Yes
Issuer whitelist validation (issuerID, issuerState)	No	Yes
Revocation status checks (issuerClaimNonRevState)	No	Yes
Replay attack prevention (challenge, gistRoot)	No	Yes
Proof timeliness (timestamp)	No	Yes
Nullifier generation for anti-Sybil	No	Yes

An AI agent verifying a complex user profile will typically process a request that includes both components: a multi-query component for the data attributes and a core verification component to validate the cryptographic integrity and security of the credential itself. Both components must share the same groupID to prove they refer to the same session and the same underlying identity.

// Secure integration: LinkedMultiQuery + Core Verification Circuit
const secureSetup = {
  requests: [
    {
      requestId: 1,
      validator: linkedMultiQueryValidatorAddress,  // Batch queries
      params: linkedQueryParams
    },
    {
      requestId: 2,
      validator: coreVerificationValidatorAddress,  // Security checks
      params: securityParams
    }
  ],
  multiRequest: {
    multiRequestId: 100,
    groupIds: [1],  // Ensures linkID consistency across both requests
    requestIds: [1, 2]
  }
};

Linked Proofs Across Sessions

Beyond a single batch query, the architecture supports linking proofs across entirely different sessions or requests. The verifyLinkedProofs(sender, requestIds) smart contract function checks that all submitted proofs share the same linkID:

function verifyLinkedProofs(
    address sender,
    uint64[] calldata requestIds
) public view virtual {
    require(requestIds.length > 1, "Linked proof verification needs more than 1 request");
    uint256 expectedLinkID = getProofStorageField(sender, requestIds[0], LINKED_PROOF_KEY);
    // Verify all subsequent proofs share the same linkID...
}

This proves that the same underlying credential and identity were used across different interactions, enabling agents to build continuous context about a user without learning their actual identity.

---

Delegated Proofs

In the expanding agent economy, a user might employ multiple AI agents across different platforms (e.g., a trading agent on Arbitrum and a gaming agent on Base). Delegated Proofs allow a Holder to bind their verified identity to multiple addresses or delegate verification capabilities to specific AI agents without needing to repeat the costly and time-consuming credential issuance process.

The Delegation Process

1. Primary Identity Establishment: The Holder establishes their primary identity through a KYC/KYB process and receives verifiable credentials in their main secure wallet (the SSI Wallet).

2. Authorization: The Holder signs a cryptographic transaction authorizing the delegation of specific credential proofs to a secondary address or a specific AI agent’s DID. This authorization defines the exact scope of what the delegate is allowed to prove. The zkMe Delegate Smart Contract facilitates this cross-chain data transfer.

3. Delegate Minting: The smart contract infrastructure verifies the authorization signature and mints a delegate copy of the proof. This takes the form of a non-transferable token (a Soulbound Token) bound to the secondary address or the agent’s identifier. The delegate copy contains the Holder’s DIDs, a key shard, and a pointer to the verified ZKP, but does not contain the raw credential data.

Security and Revocation

The critical security mechanism of Delegated Proofs is the strict cryptographic tether to the primary credential.

If the primary credential is revoked by the issuer (e.g., due to an expired passport or a change in compliance status) or deleted by the user, all associated delegate copies across all platforms and agents become instantly invalid during any subsequent verification attempt. This is enforced through the multi-layer revocation check described in the Credential System architecture: the on-chain State Contract is queried for revocation status, the expiration date is verified, and the ZK circuit enforces both constraints during proof generation.

The Agent Trust Gateway checks the revocation status of the parent credential before accepting a delegated Agent-Ready Credential. This architecture ensures that the user maintains absolute sovereignty over their identity footprint, even when delegating autonomous execution rights to multiple agents across multiple chains.