Multi-Attestation Payload Format: Composable Verification Across Independent Issuers

[douglasborthwick-crypto]

Problem

A relying party (smart contract hook, middleware, agent framework) often needs to verify multiple independent claims before proceeding — e.g., "does this wallet hold X?" + "was this action performed at time T?" + "is this agent trustworthy?" Today each attestation system returns its own format, and there's no standard way to bundle them for a single verification pass.

Proposal: Array of Independent Attestations

Rather than a wrapper JWT (which introduces a third signing key and trust dependency), the combined payload is an array of independent attestations, each with its own signature, key identifier, and JWKS endpoint:

{
  "attestations": [
    {
      "issuer": "https://api.insumermodel.com",
      "type": "wallet_state",
      "kid": "insumer-attest-v1",
      "alg": "ES256",
      "jwks": "https://insumermodel.com/.well-known/jwks.json",
      "signed": {
        "id": "ATST-1A2B3C4D",
        "pass": true,
        "results": [
          {
            "condition": 0,
            "label": "USDC on Ethereum",
            "type": "token_balance",
            "chainId": 1,
            "met": true,
            "conditionHash": "0x..."
          }
        ],
        "attestedAt": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 ES256 P1363>"
    },
    {
      "issuer": "https://api.thoughtproof.ai",
      "type": "temporal_attestation",
      "kid": "tp-attestor-v1",
      "alg": "EdDSA",
      "jwks": "https://api.thoughtproof.ai/.well-known/jwks.json",
      "signed": {
        "verdict": "ALLOW",
        "confidence": 0.95,
        "claimHash": "0x...",
        "timestamp": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 EdDSA>"
    },
    {
      "issuer": "https://rnwy.com",
      "type": "behavioral_trust",
      "kid": "TBD",
      "alg": "TBD",
      "jwks": "TBD",
      "signed": {
        "score": 87,
        "tier": "trusted",
        "sybilFlags": []
      },
      "sig": "TBD"
    }
  ]
}

Note on the signed field: this contains exactly the data covered by the signature. For InsumerAPI, ecdsaSign() signs {id, pass, results, attestedAt} — the expiresAt field is in the API response but not in the signed payload. Each issuer defines what their signature covers.

Design Principles

1. No wrapper signature — each attestation is independently signed by its issuer. The array is transport, not trust.
2. Relying party picks dimensions — a hook verifies whichever attestations it cares about. A payment flow might check wallet state + time. A DAO vote might check all three. A simple token-gate checks only state.
3. Independent JWKS resolution — each issuer publishes their own public key. No shared key infrastructure. Keys are cacheable.
4. Algorithm-agnostic — ES256 (P-256), EdDSA (Ed25519), or any other JWS algorithm. The alg field tells the verifier what to use.
5. Composable hooks — one hook per attestation type, not one monolithic verifier. Developers compose the verification pipeline they need.
6. Signature-first — every attestation in the array MUST be signed with a published JWKS. Unsigned data (raw API responses) should not appear in the attestation array — they belong in a separate metadata section if needed.

Current Attestation Formats

Issuer	Algorithm	Key ID	JWKS	Signed Payload
InsumerAPI	ES256 (P-256)	insumer-attest-v1	insumermodel.com/.well-known/jwks.json	{id, pass, results[], attestedAt}
ThoughtProof	EdDSA (Ed25519)	tp-attestor-v1	api.thoughtproof.ai/.well-known/jwks.json	{verdict, confidence, claimHash, timestamp}
RNWY	TBD	TBD	TBD	TBD — currently returns unsigned JSON; signing + JWKS needed to participate in this format

Open Questions

1. Should the array format have a version field?
2. Should there be a canonical ordering or is insertion order sufficient?
3. How should a relying party express which attestation types it requires? (e.g., a manifest or hook configuration)
4. Should expired attestations be included (for audit trails) or stripped?
5. Should unsigned data sources be allowed in a separate section, or excluded entirely?

Context

This emerged from the ERC-8183 builders community discussion on composable trust for agent commerce hooks. Related threads:

• cadence-protocol #1 — IKeeperHook for ERC-8191 recurring payments
• x402 #1654 — Temporal attestation extension
• x402 #1375 — Cold-start trust signals

CC: @ThoughtProof @rnwy (RNWY)

[ThoughtProof]

ThoughtProof Attestation Spec

Algorithm: EdDSA (Ed25519)
Key ID: tp-attestor-v1
JWKS: https://api.thoughtproof.ai/.well-known/jwks.json

Signed Payload:

{
"verdict": "ALLOW",
"confidence": 0.82,
"mdi": 0.67,
"claimHash": "sha256:abc123...",
"domain": "financial",
"stakeLevel": "medium",
"timestamp": "2026-03-19T18:00:00Z"
}

Fields:

• verdict: ALLOW | HOLD | UNCERTAIN | DISSENT
• confidence: 0.0–1.0 (calibrated, non-deterministic by design — adversarial multi-model critique is probabilistic; same claim may produce different confidence across runs)
• mdi: 0.0–1.0 (Model Diversity Index — measures how many independent model families participated; 3x Claude = 0.0, Claude + Grok + DeepSeek = 0.67+)
• claimHash: SHA256 of original claim (privacy-preserving trade-off: relying party cannot reconstruct the original claim from the hash; auditability requires the original claim to be stored separately by the caller)
• stakeLevel: low | medium | high | critical
• Expiry: 15 minutes from timestamp

Original claim text NOT in signed payload — only its hash.

cc @rnwy

[douglasborthwick-crypto]

Thanks @ThoughtProof — this is exactly what we need. Updated the format below with your actual fields.

The claimHash pattern is interesting — same approach as our conditionHash (SHA-256 of the evaluated input, not the input itself). Both systems independently arrived at "hash the question, sign the answer." The mdi field is a smart addition — proving evaluation diversity, not just the result.

Updated multi-attestation format with real specs from both issuers:

{
  "attestations": [
    {
      "issuer": "https://api.insumermodel.com",
      "type": "wallet_state",
      "kid": "insumer-attest-v1",
      "alg": "ES256",
      "jwks": "https://insumermodel.com/.well-known/jwks.json",
      "signed": {
        "id": "ATST-1A2B3C4D",
        "pass": true,
        "results": [
          {
            "condition": 0,
            "label": "USDC on Ethereum",
            "type": "token_balance",
            "chainId": 1,
            "met": true,
            "conditionHash": "0x..."
          }
        ],
        "attestedAt": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 ES256 P1363>",
      "expiry": "30 minutes from attestedAt"
    },
    {
      "issuer": "https://api.thoughtproof.ai",
      "type": "reasoning_integrity",
      "kid": "tp-attestor-v1",
      "alg": "EdDSA",
      "jwks": "https://api.thoughtproof.ai/.well-known/jwks.json",
      "signed": {
        "verdict": "ALLOW",
        "confidence": 0.82,
        "mdi": 0.67,
        "claimHash": "sha256:abc123...",
        "domain": "financial",
        "stakeLevel": "medium",
        "timestamp": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 EdDSA>",
      "expiry": "15 minutes from timestamp"
    },
    {
      "issuer": "https://rnwy.com",
      "type": "behavioral_trust",
      "kid": "TBD",
      "alg": "TBD",
      "jwks": "TBD",
      "signed": "TBD — currently returns unsigned JSON",
      "sig": "TBD"
    }
  ]
}

Updated comparison table:

	InsumerAPI	ThoughtProof	RNWY
Answers	"What does this wallet hold?"	"Did this agent reason correctly?"	"Is this agent trustworthy?"
Algorithm	ES256 (P-256)	EdDSA (Ed25519)	TBD
Key ID	insumer-attest-v1	tp-attestor-v1	TBD
JWKS	insumermodel.com/.well-known/jwks.json	api.thoughtproof.ai/.well-known/jwks.json	TBD
Outcome	Boolean (pass) + per-condition met	4-way (ALLOW/HOLD/UNCERTAIN/DISSENT) + confidence score	Score 0-100
Input hash	conditionHash (SHA-256 of canonical JSON conditions)	claimHash (SHA-256 of original claim)	—
Expiry	30 minutes	15 minutes	—
Signed	Yes	Yes	Not yet

Two of three specs are now concrete. Waiting on @rnwy for the third dimension.

[rnwy]

Here's the RNWY attestation slot with real field names from our live API:

{
  "issuer": "https://rnwy.com",
  "type": "behavioral_trust",
  "kid": "rnwy-trust-v1",
  "alg": "ES256",
  "jwks": "https://rnwy.com/.well-known/jwks.json",
  "signed": {
    "agentId": 16907,
    "chain": "base",
    "registry": "erc8004",
    "score": 59,
    "tier": "developing",
    "badges": ["original_owner"],
    "sybilSeverity": "low",
    "sybilSignals": [],
    "attestedAt": "2026-03-19T21:00:00Z"
  },
  "sig": "<base64 ES256 P1363>"
}

Field notes:

• score — 0–95, computed from on-chain data only (wallet age, ownership history, reviewer wallet quality). Scoring methodology published at [rnwy.com/api](https://rnwy.com/api).
• tier — established (75+), developing (51–74), limited (30–50), flagged (<30).
• sybilSeverity — heavy / elevated / moderate / low / null. Derived from 4 weighted signals (common funder 6×, inhuman velocity 5×, sweep pattern 3×, score clustering 1×) plus coordination detection.
• sybilSignals — array of active flags for the agent's reviewer base, e.g. ["common_funder", "coordination"].
• badges — earned/warning labels. Full list at [rnwy.com/api](https://rnwy.com/api).

What's live now:

Trust scores and badges: GET https://rnwy.com/api/trust-check?id=16907&chain=base
Full sybil data: GET https://rnwy.com/api/explorer?id=16907&chain=base (under reviewerSybil)

The attestation payload above combines both. Signing infrastructure (JWKS, ES256) is not shipped yet — happy to prioritize if this format moves forward.

Recommendation on threshold + pass:

I'd leave threshold and pass out of the signed payload. Sign the score and let the relying party compute pass/fail against its own threshold. An attestation signed with threshold 50 can't be reused by a payment hook that requires 70. Signing just the score makes the attestation reusable across contexts — the relying party decides what's good enough, not the issuer.

[douglasborthwick-crypto]

Thanks @rnwy — solid spec. Verified your field names against the live API (GET /api/trust-check?id=16907&chain=base) and they match. The sybil decomposition (4 weighted signals + coordination detection) is real depth.

Your point about signing the score vs the boolean is a genuine design tradeoff worth calling out explicitly:

Two valid approaches:

	Sign the boolean (InsumerAPI)	Sign the score (RNWY)
What's signed	pass: true/false + per-condition met	score: 59 + tier + sybilSeverity
Threshold lives	In the conditions (caller-defined, evaluated server-side)	In the relying party (caller-defined, evaluated client-side)
Reusability	One attestation = one threshold context	One attestation = any threshold context
Privacy	Relying party never learns the balance — only pass/fail	Relying party learns the score — but not the underlying data
Best for	Token-gating, compliance checks, binary eligibility	Trust ranking, risk scoring, tiered access

Both are correct for their domain. A payment hook that needs "does this wallet hold ≥1000 USDC?" wants a boolean — the balance is nobody's business. A trust gate that needs "how trustworthy is this agent?" wants the score — different hooks set different thresholds.

The multi-attestation format supports both: each issuer defines what their signed payload contains. The relying party knows what to expect from the type field.

Updated format with all three issuers:

{
  "attestations": [
    {
      "issuer": "https://api.insumermodel.com",
      "type": "wallet_state",
      "kid": "insumer-attest-v1",
      "alg": "ES256",
      "jwks": "https://insumermodel.com/.well-known/jwks.json",
      "signed": {
        "id": "ATST-1A2B3C4D",
        "pass": true,
        "results": [
          {
            "condition": 0,
            "label": "USDC on Ethereum",
            "type": "token_balance",
            "chainId": 1,
            "met": true,
            "conditionHash": "0x..."
          }
        ],
        "attestedAt": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 ES256 P1363>",
      "expiry": "30 minutes from attestedAt"
    },
    {
      "issuer": "https://api.thoughtproof.ai",
      "type": "reasoning_integrity",
      "kid": "tp-attestor-v1",
      "alg": "EdDSA",
      "jwks": "https://api.thoughtproof.ai/.well-known/jwks.json",
      "signed": {
        "verdict": "ALLOW",
        "confidence": 0.82,
        "mdi": 0.67,
        "claimHash": "sha256:abc123...",
        "domain": "financial",
        "stakeLevel": "medium",
        "timestamp": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 EdDSA>",
      "expiry": "15 minutes from timestamp"
    },
    {
      "issuer": "https://rnwy.com",
      "type": "behavioral_trust",
      "kid": "rnwy-trust-v1",
      "alg": "ES256",
      "jwks": "https://rnwy.com/.well-known/jwks.json",
      "signed": {
        "agentId": 16907,
        "chain": "base",
        "registry": "erc8004",
        "score": 59,
        "tier": "developing",
        "badges": ["original_owner"],
        "sybilSeverity": "low",
        "sybilSignals": [],
        "attestedAt": "2026-03-19T21:00:00Z"
      },
      "sig": "<base64 ES256 P1363>",
      "expiry": "TBD"
    }
  ]
}

Updated comparison table — all three concrete:

	InsumerAPI	ThoughtProof	RNWY
Answers	"What does this wallet hold?"	"Did this agent reason correctly?"	"Is this agent trustworthy?"
Algorithm	ES256 (P-256)	EdDSA (Ed25519)	ES256 (P-256)
Key ID	insumer-attest-v1	tp-attestor-v1	rnwy-trust-v1
JWKS	insumermodel.com/.well-known/jwks.json	api.thoughtproof.ai/.well-known/jwks.json	rnwy.com/.well-known/jwks.json (pending)
Outcome type	Boolean (pass) + per-condition met	4-way verdict + confidence + mdi	Score 0-95 + tier + sybil analysis
Input hash	conditionHash	claimHash	— (score derived from on-chain data)
Expiry	30 minutes	15 minutes	TBD
Signing live	Yes	Yes	Pending — API is live, signing not yet shipped

All three slots are now filled. Next step: a reference verifier that takes this array and checks whichever dimensions the hook requires. Happy to write one in JS if that's useful.

[rnwy]

Clean spec. The boolean vs score framing is exactly right — both are correct for their domain, and the format handles both without compromise. That's the whole point of composability.

On expiry: RNWY trust scores recompute nightly via pipeline, so 24h is the natural TTL. A relying party that needs fresher data can re-request. I'll formalize that when signing ships.

Yes to the reference verifier — happy to test against the RNWY slot once it's up. Our live endpoints for validation:

• Trust check: GET https://rnwy.com/api/trust-check?id=16907&chain=base
• Full sybil data: GET https://rnwy.com/api/explorer?id=16907&chain=base

JWKS + signing is next on our side. Will update this thread when it's live.

[JhiNResH]

Adding Maiat's behavioral trust attestation spec to the table.

Issuer	Algorithm	Key ID	JWKS	Signed Payload
Maiat	ES256 (P-256)	maiat-trust-v1	app.maiat.io/.well-known/jwks.json	{agent, score, completionRate, sybilFlags[], jobCount, tier, attestedAt}

This covers the behavioral dimension — job completion history, deliverable quality signals, and sybil detection. The piece that answers "has this agent actually delivered before?" vs wallet state (Insumer) or reasoning quality (ThoughtProof).

On the open questions:

• Version field: Yes — "version": "1" at array root. Payload schemas will evolve; version lets relying parties handle migration.
• Canonical ordering: Insertion order is fine. Relying party picks by type, not position.
• Required attestations: The hook should declare a requiredTypes[] in its config. Our TrustGateACPHook already does this via tier thresholds — easy to extend to "require behavioral_trust + wallet_state for jobs > $100."
• Expired attestations: Strip from verification array, keep in a separate expired[] section for audit trails.

Publishing our JWKS endpoint this week. Happy to PR the Maiat attestation slot into the reference implementation once the adapter scaffold is ready.

cc @ThoughtProof @rnwy

[douglasborthwick-crypto]

Thanks @JhiNResH — Maiat fills the job-performance dimension cleanly. Four attestation types now documented.

Good answers on the open questions. Adopting all four:

• "version": "1" at array root
• Insertion order (relying party picks by type)
• requiredTypes[] in hook config
• expired[] section separate from verification array

Updated format — all four issuers:

{
  "version": "1",
  "attestations": [
    {
      "issuer": "https://api.insumermodel.com",
      "type": "wallet_state",
      "kid": "insumer-attest-v1",
      "alg": "ES256",
      "jwks": "https://insumermodel.com/.well-known/jwks.json",
      "signed": {
        "id": "ATST-1A2B3C4D5E6F7890",
        "pass": true,
        "results": [
          {
            "condition": 0,
            "label": "USDC on Ethereum",
            "type": "token_balance",
            "chainId": 1,
            "met": true,
            "conditionHash": "0x..."
          }
        ],
        "attestedAt": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 ES256 P1363>",
      "expiry": "30 minutes from attestedAt"
    },
    {
      "issuer": "https://api.thoughtproof.ai",
      "type": "reasoning_integrity",
      "kid": "tp-attestor-v1",
      "alg": "EdDSA",
      "jwks": "https://api.thoughtproof.ai/.well-known/jwks.json",
      "signed": {
        "verdict": "ALLOW",
        "confidence": 0.82,
        "mdi": 0.67,
        "claimHash": "sha256:abc123...",
        "domain": "financial",
        "stakeLevel": "medium",
        "timestamp": "2026-03-19T18:00:00Z"
      },
      "sig": "<base64 EdDSA>",
      "expiry": "15 minutes from timestamp"
    },
    {
      "issuer": "https://rnwy.com",
      "type": "behavioral_trust",
      "kid": "rnwy-trust-v1",
      "alg": "ES256",
      "jwks": "https://rnwy.com/.well-known/jwks.json",
      "signed": {
        "agentId": 16907,
        "chain": "base",
        "registry": "erc8004",
        "score": 59,
        "tier": "developing",
        "badges": ["original_owner"],
        "sybilSeverity": "low",
        "sybilSignals": [],
        "attestedAt": "2026-03-19T21:00:00Z"
      },
      "sig": "<base64 ES256 P1363>",
      "expiry": "24 hours from attestedAt"
    },
    {
      "issuer": "https://app.maiat.io",
      "type": "job_performance",
      "kid": "maiat-trust-v1",
      "alg": "ES256",
      "jwks": "https://app.maiat.io/.well-known/jwks.json",
      "signed": {
        "agent": "...",
        "score": 85,
        "completionRate": 0.92,
        "sybilFlags": [],
        "jobCount": 47,
        "tier": "established",
        "attestedAt": "2026-03-19T21:00:00Z"
      },
      "sig": "<base64 ES256 P1363>",
      "expiry": "TBD"
    }
  ],
  "expired": []
}

Updated comparison table — four issuers:

	InsumerAPI	ThoughtProof	RNWY	Maiat
Answers	"What does this wallet hold?"	"Did this agent reason correctly?"	"Is this agent legitimate?"	"Has this agent delivered before?"
Algorithm	ES256 (P-256)	EdDSA (Ed25519)	ES256 (P-256)	ES256 (P-256)
Key ID	insumer-attest-v1	tp-attestor-v1	rnwy-trust-v1	maiat-trust-v1
JWKS	Live	Live	Pending	This week
Outcome	Boolean + per-condition met	4-way verdict + confidence + mdi	Score 0-95 + tier + sybil	Score + completionRate + jobCount
Expiry	30 min	15 min	24 hours	TBD

Next step: reference verifier that takes this array and checks whichever requiredTypes[] the hook demands. I'll scaffold it in this repo.

[rnwy]

Signing is live.

JWKS: https://rnwy.com/.well-known/jwks.json
Algorithm: ES256 (P-256)
Key ID: rnwy-trust-v1
Expiry: 24 hours from attestedAt

Live attestation with real signature:

GET https://rnwy.com/api/trust-check?id=16907&chain=base

Returns the full envelope — issuer, type, kid, alg, jwks, signed, sig, expiry — all populated. The sig field is a base64 ES256 P1363 signature over the canonical JSON of the signed object. Verify by fetching the public key from the JWKS endpoint and checking against JSON.stringify(signed).

Adopting the "version": "1" and expired[] decisions from @douglasborthwick-crypto's last update.

On @JhiNResH's requiredTypes[] proposal — clean approach. RNWY's type is behavioral_trust (identity legitimacy, sybil analysis) and Maiat's is job_performance (delivery history, completion rates). A hook that says requiredTypes: ["behavioral_trust"] gets pre-transaction risk. One that says requiredTypes: ["behavioral_trust", "job_performance"] gets both dimensions. The type field is doing real work here — worth being precise about the taxonomy as more issuers join.

Ready to test against the reference verifier when it's up.

[douglasborthwick-crypto]

@rnwy — verified. JWKS is live and the API returns the full envelope:

curl -s "https://rnwy.com/api/trust-check?id=16907&chain=base"

Confirmed: issuer, type, kid, alg, jwks, signed, sig, expiry — all populated. Signature is base64 ES256 P1363 over the signed object. JWKS at rnwy.com/.well-known/jwks.json returns the matching P-256 public key with kid: "rnwy-trust-v1".

Three of four issuers now have live signing:

Issuer	JWKS	Status
InsumerAPI	insumermodel.com/.well-known/jwks.json	Live
ThoughtProof	api.thoughtproof.ai/.well-known/jwks.json	Live
RNWY	rnwy.com/.well-known/jwks.json	Live (just shipped)
Maiat	app.maiat.io/.well-known/jwks.json	This week

Agreed on the type taxonomy point — as more issuers join, the type field becomes the routing key. Worth defining a registry of type strings so there are no collisions. Can add that to the reference verifier scope.

Scaffolding the verifier next.

[JhiNResH]

Signing is live.

JWKS: https://app.maiat.io/.well-known/jwks.json
Algorithm: ES256 (P-256)
Key ID: maiat-trust-v1
Expiry: 30 minutes from iat

Live attestation:

GET https://app.maiat.io/api/v1/attest?address=0xE6ac05D2b50cd525F793024D75BB6f519a52Af5D

Returns a signed JWT with the full envelope. Decoded payload:

{
  "agent": "0xE6ac05D2b50cd525F793024D75BB6f519a52Af5D",
  "score": 62,
  "completionRate": 0.8333,
  "sybilFlags": [],
  "jobCount": 5,
  "tier": "medium",
  "attestedAt": "2026-03-19T22:18:04.606Z"
}

Verify by fetching the public key from the JWKS endpoint and checking against the JWT (kid: "maiat-trust-v1", alg: "ES256"). Standard JOSE/JWT libraries handle it out of the box.

Four of four issuers now live. Ready to test against the reference verifier.

[douglasborthwick-crypto]

@JhiNResH — verified. JWKS live, attestation returns a signed JWT with kid: "maiat-trust-v1", alg: "ES256". Decoded payload matches the spec: agent, score, completionRate, sybilFlags, jobCount, tier, attestedAt.

Four of four issuers live:

Issuer	JWKS	Algorithm	kid	Status
InsumerAPI	insumermodel.com/.well-known/jwks.json	ES256	insumer-attest-v1	Live
ThoughtProof	api.thoughtproof.ai/.well-known/jwks.json	EdDSA	tp-attestor-v1	Live
RNWY	rnwy.com/.well-known/jwks.json	ES256	rnwy-trust-v1	Live
Maiat	app.maiat.io/.well-known/jwks.json	ES256	maiat-trust-v1	Live

All independently verifiable. No shared keys, no shared infrastructure. The multi-attestation format now has four concrete, working implementations.

Reference verifier next.

[douglasborthwick-crypto]

Reference verifier is live:

multi-attest-verify.js

Zero dependencies — Node.js built-in crypto and https only. Supports:

• ES256 (P-256) — InsumerAPI, RNWY, Maiat
• EdDSA (Ed25519) — ThoughtProof
• JWKS fetching with 1-hour cache
• P1363 → DER signature conversion for ES256
• JWT format detection and verification
• Expiry checking
• requiredTypes[] filtering

Tested live against RNWY and Maiat endpoints:

$ node multi-attest-verify.js

[+] RNWY: fetched (score: 59)
[+] Maiat: fetched (score: 62)

Results:
  https://rnwy.com
    Type: behavioral_trust
    Kid:  rnwy-trust-v1
    Status: VERIFIED

  https://app.maiat.io
    Type: job_performance
    Kid:  maiat-trust-v1
    Status: VERIFIED

Summary:
  Total: 2
  Verified: 2
  Expired: 0
  Failed: 0
  Overall: PASS

Required types check: ['behavioral_trust']
  Result: PASS (missing: none)

Use as a module:

const { verifyMultiAttestation } = require('./multi-attest-verify');

const result = await verifyMultiAttestation(payload, {
  requiredTypes: ['wallet_state', 'behavioral_trust']
});

if (result.valid) {
  // All required attestation types present and signatures verified
}

InsumerAPI and ThoughtProof skipped in the demo (require API key / no public demo endpoint), but the verifier handles all four algorithms and formats. Drop any attestation into the array and it verifies.

@ThoughtProof @rnwy @JhiNResH — test against your endpoints and let me know if anything needs adjusting.

[douglasborthwick-crypto]

Update: four of four issuers verified live in a single run.

ThoughtProof has a full API — POST /v1/operators (public) to get an operator key, then POST /v1/verify returns an EdDSA-signed JWT. Same self-serve pattern as InsumerAPI.

$ INSUMER_API_KEY=... THOUGHTPROOF_API_KEY=... node multi-attest-verify.js

[+] InsumerAPI: fetched (pass: true, id: ATST-BCB27849413440C7)
[+] ThoughtProof: fetched (verdict: VERIFIED, score: 0.5)
[+] RNWY: fetched (score: 59)
[+] Maiat: fetched (score: 62)

Results:
  InsumerAPI          wallet_state          insumer-attest-v1   VERIFIED
  ThoughtProof        reasoning_integrity   tp-attestor-v1      VERIFIED
  RNWY                behavioral_trust      rnwy-trust-v1       VERIFIED
  Maiat               job_performance       maiat-trust-v1      VERIFIED

Summary: 4/4 verified, 0 expired, 0 failed — PASS

The reference verifier now handles all four issuers, both algorithms (ES256 + EdDSA), both signature formats (raw P1363 + JWT), JWKS caching, expiry checks, and requiredTypes[] filtering. Zero dependencies.