IICP Conformance Badges

Conformance is how IICP moves from “someone says it works” to “the implementation passed shared checks.” Badges help users compare implementations without relying on marketing.

What a badge should mean

Shared tests

Every implementation should be checked against the same expected behaviour.

Visible evidence

A badge should point to results that others can inspect.

Limited claims

Passing tests does not prove safety, quality, or uptime for every situation.

See live nodes →Read the spec How rules change

Want to test IICP without joining the implementation team? The external evidence campaign lists bounded tasks for independent implementers, operators, reviewers, and newcomers. Blank templates are preparation, not evidence.

The S.14 conformance badge system lets implementations publish evidence for specific IICP tiers. Every badge is a signed attestation record, and its verification mode states whether the subject signed its own results or the Genesis verifier ran and signed them. Neither mode is a legal compliance certificate.

Full specification: conformance badge specification · Schema: badge JSON schema

Conformance tiers

iicp:core:v1Core

Implements intent-based discovery and registration (Phase 1). Required by all IICP participants.

·GET /v1/discover
·POST /v1/register
·POST /v1/heartbeat
·JWT auth, HMAC signing

iicp:mesh:v1Mesh

Adds peer exchange, gossip, and mesh bootstrap (Phase 2). Required for nodes that participate in bootstrapping.

·GET /v1/bootstrap
·POST /v1/peers (HMAC-SHA256)
·PeerManager gossip ≤ 30s
·Stale prune ≤ 90s

iicp:sdk:v1SDK

Client-side SDK conformance — intent dispatch, result collection, retry policy (Phase 3+).

·Intent dispatch per S.4
·Retry policy per S.9
·W3C traceparent propagation
·CIP profile support (S.12)

iicp:federated:v1Federated

Federated control plane node — replicates signed directory lifecycle state under the Phase 6 conflict and recovery rules.

·Directory replication (S.13)
·Replica health probes
·Conflict resolution policy
·Federated registration

iicp:full:v1Full

All tiers combined. Reserved for implementations that pass core + mesh + sdk + federated suites.

·All Core requirements
·All Mesh requirements
·All SDK requirements
·All Federated requirements

How to obtain a badge

1
Run the conformance test suite
Clone the IICP conformance test suite and run it against your implementation. Record the full JSON results.
2
Self-attest or request Genesis verification
Self-attested badges are valid for testing and community use. Genesis Seed verification (did:web:iicp.network) is required for Tier attestation in the public registry.
3
Sign the badge record
Compute the Ed25519 signature over badge_id:tier:subject_did:passed_at:SHA256_hex(canonical_json(test_results)) and embed it in the badge JSON.
4
Publish badge and test results URL
Host the badge JSON and test results at a stable URL. Both must remain accessible for ≥ 90 days (BADGE-03, BADGE-06).
5
Embed the badge in your documentation
Link to the hosted badge JSON from your project's README or website. Use the SVG shield format defined in S.14 §6.

Help produce external evidence

IICP has public, version-pinned participation lanes for a clean-room directory, newcomer usability, Linux/systemd supervision, relay eligibility, qualified review, and standards governance. Each lane states who controls the environment, which artifact to test, how to validate the result, and what the result cannot prove.

Project verification is not independent evidence. Independence requires an outside party to control the relevant implementation or environment and publish its own result.

Choose an external evidence lane →

Badge record format

A badge is a JSON object validated against the badge JSON schema. Required fields:

{
  "badge_id":        "550e8400-e29b-41d4-a716-446655440000",  // UUID v4
  "tier":            "iicp:core:v1",
  "subject_did":     "did:web:node.example.com",
  "subject_component": "adapter",
  "suite_version":   "1.0.0",
  "passed_at":       "2026-05-17T00:00:00Z",
  "expires_at":      "2026-08-15T00:00:00Z",                  // +90 days (BADGE-03)
  "test_results_url": "https://example.com/iicp-results.json",
  "issuer_did":      "did:web:iicp.network",                   // or subject_did for self-attested
  "verification_mode": "genesis-verified",
  "sig":             "<base64url Ed25519 signature>"
}

Signature input: badge_id:tier:subject_did:passed_at:SHA256_hex(canonical_json(test_results))

Verification model

Project verification · Genesis-verified

The IICP project's Genesis Seed (did:web:iicp.network) ran the conformance suite against your implementation and signed the badge. This is project-verified evidence, not an independent implementation or third-party result; it is shown with the verified shield in the public registry (BADGE-05).

Subject assertion · Self-attested

Your own DID signs the badge. Valid for development, community demos, and internal testing. issuer_did equals subject_did. Not shown in public registry by default.

Badge expiry: 90 days from passed_at (BADGE-03). The test results URL must remain accessible for the same period (BADGE-06).

✓

Badge API — live

The conformance badge API is served by the Genesis Seed directory:

POST /api/v1/conformance/submit — register a badge (self-attested, or genesis-verified when issuer_did=did:web:iicp.network).
GET /api/v1/conformance/verify?did=&tier= — check whether a valid (non-expired) badge exists for a DID and tier.
GET /api/v1/conformance/badges?did=— list a subject's badges.
GET /api/v1/badge/{tier} — expiry-aware SVG shield (BADGE-04).

Self-attested badges can also be generated locally using the public badge schema and signing procedure in the conformance documentation.

← Protocol spec Node directory →Governance →