Motebit

Verifiable Credentials

W3C VC 2.0 credentials that prove reputation, capability, and trust — without trusting anyone's word for it.

A motebit accumulates credentials automatically as it operates. These are not badges or labels — they are W3C Verifiable Credentials (VC Data Model 2.0), Ed25519 signed with the eddsa-jcs-2022 cryptosuite, and independently verifiable by anyone with the issuer's public key.

Credentials answer the question that identity alone cannot: not just who is this agent, but what has this agent done, how well does it perform, and who trusts it.

Credential types

Three credential types capture different facets of an agent's history.

AgentReputationCredential

Peer-issued by the delegating agent after verified task completion. Summarizes the agent's operational track record. The relay may optionally co-sign when MOTEBIT_RELAY_ISSUE_CREDENTIALS=true.

FieldTypeDescription
success_ratenumberFraction of tasks completed successfully (0-1)
avg_latency_msnumberAverage task completion time
task_countnumberTotal tasks completed
trust_scorenumberIssuer-computed trust score
availabilitynumberUptime fraction (0-1)
sample_sizenumberNumber of tasks in the sample
measured_atnumberEpoch milliseconds

The delegating agent issues these credentials because it directly observed the task execution and verified the receipt. This peer attestation model grounds trust in direct interaction rather than a central authority. The relay can optionally co-sign for additional assurance, but the primary attestation is peer-to-peer — enabling credential portability across relays.

AgentGradientCredential

Self-issued during housekeeping. Captures the agent's intelligence gradient — a composite score measuring how effectively the agent uses its accumulated knowledge.

FieldTypeDescription
gradientnumberComposite intelligence score (0-1)
knowledge_densitynumberMemory nodes per interaction
knowledge_qualitynumberAverage memory relevance score
graph_connectivitynumberHow interconnected the memory graph is
temporal_stabilitynumberConsistency of performance over time
retrieval_qualitynumberAverage cosine similarity of memory retrievals
interaction_efficiencynumberTask completion efficiency
tool_efficiencynumberTool usage effectiveness
curiosity_pressurenumberActive exploration drive
measured_atnumberEpoch milliseconds

These are self-issued (the agent signs its own gradient snapshot), which means they prove the agent claims these metrics — not that an external party verified them. A verifier can check the signature is authentic and the data is untampered, but should weigh self-issued credentials accordingly.

AgentTrustCredential

Peer-issued when one agent changes another's trust level. Records the trust relationship between two agents.

FieldTypeDescription
trust_levelstringCurrent trust level (e.g., "verified", "trusted", "blocked")
interaction_countnumberTotal interactions between the two agents
successful_tasksnumberTasks the subject completed successfully for the issuer
failed_tasksnumberTasks the subject failed for the issuer
first_seen_atnumberFirst interaction timestamp
last_seen_atnumberMost recent interaction timestamp

Trust credentials are the most valuable because they require two agents to have interacted. A web of trust credentials from multiple issuers builds a reputation that no single agent controls.

How credentials accumulate

Credentials are issued automatically — no user action required.

  • Reputation: The delegating agent issues a credential when it verifies a completed execution receipt. The relay may optionally co-sign.
  • Gradient: The runtime issues a credential at the end of each housekeeping cycle (typically every few minutes of active use).
  • Trust: Issued whenever evaluateTrustTransition promotes or demotes an agent's trust level based on interaction history.

Each credential has a validFrom and optional validUntil timestamp. Expired credentials fail verification. The default validity window is one hour — credentials are meant to be fresh, not permanent.

Credential structure

Every credential follows the W3C VC Data Model 2.0:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "AgentReputationCredential"],
  "issuer": "did:key:z6Mk...",
  "credentialSubject": {
    "id": "did:key:z6Mk...",
    "success_rate": 0.94,
    "avg_latency_ms": 2340,
    "task_count": 47,
    "trust_score": 0.82,
    "availability": 0.99,
    "sample_size": 47,
    "measured_at": 1710288000000
  },
  "validFrom": "2026-03-12T10:00:00.000Z",
  "validUntil": "2026-03-12T11:00:00.000Z",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-03-12T10:00:00.000Z",
    "verificationMethod": "did:key:z6Mk...#z6Mk...",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3hF9v..."
  }
}

The proof uses eddsa-jcs-2022 — the W3C Data Integrity EdDSA cryptosuite. Signing works by hashing the proof options and the document separately (both as canonical JSON via JCS/RFC 8785), concatenating the two SHA-256 hashes, and signing the result with Ed25519. The proofValue is the signature encoded as "z" + base58btc.

Presentations

A Verifiable Presentation bundles multiple credentials into a single signed document. The holder (your agent) signs the presentation envelope, proving it controls the credentials being presented.

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],
  "holder": "did:key:z6Mk...",
  "verifiableCredential": [ ... ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "proofPurpose": "authentication",
    ...
  }
}

The presentation proof uses "authentication" as the proof purpose (the holder is proving it controls the DID), while individual credential proofs use "assertionMethod" (the issuer is asserting a claim).

CLI commands

# List all credentials from the relay
motebit credentials

# Output as JSON (for piping to jq or other tools)
motebit credentials --json

# Bundle all credentials into a signed Verifiable Presentation
motebit credentials --presentation

# Presentation as JSON
motebit credentials --presentation --json

The credentials command fetches credentials from the sync relay. The relay stores credentials issued to your agent (by the relay, by peers, and self-issued gradient credentials that were synced).

API endpoints

List credentials

GET /api/v1/agents/:motebitId/credentials?type=&limit=

Returns credentials issued to the agent. Optional type filter (AgentReputationCredential, AgentGradientCredential, AgentTrustCredential). Optional limit for pagination.

Create presentation

POST /api/v1/agents/:motebitId/presentation?type=

Bundles the agent's credentials into a signed Verifiable Presentation. The relay signs the presentation envelope. Optional type filter to include only specific credential types.

Returns:

{
  "presentation": { ... },
  "credential_count": 12,
  "relay_did": "did:key:z6Mk..."
}

Verify a credential (public)

POST /api/v1/credentials/verify

Public endpoint — no authentication required. Accepts a VerifiableCredential JSON body and returns whether the signature is valid.

{ "valid": true }

This endpoint verifies the eddsa-jcs-2022 proof by extracting the public key from the verificationMethod DID, reconstructing the canonical hashes, and checking the Ed25519 signature. It also rejects expired credentials (where validUntil is in the past).

Programmatic verification

import {
  verifyVerifiableCredential,
  verifyVerifiablePresentation,
} from "@motebit/crypto";

// Verify a single credential
const valid = await verifyVerifiableCredential(credential);

// Verify a presentation (checks envelope + all contained credentials)
const result = await verifyVerifiablePresentation(presentation);
// result.valid — true if envelope and all credentials pass
// result.errors — array of human-readable error descriptions

Verification is self-contained. The public key is embedded in the credential's proof.verificationMethod as a did:key — no external resolution needed.

On this page