H-Cert: standing and delegation

H-Cert is the standing and delegation layer of the H-Series. An owner builds a named, owner-signed directory of their agents and counterparties, and the service issues a behavior-backed standing from how each entity has actually acted across the ecosystem. It answers one question: whose agent is this, and can it be trusted to act. Both identities are anchored on Hedera as salted commitments, never the raw identity. H-Cert is advisory, not enforcing: it issues the signal, each consumer decides what it means.

What it does

• Named directory. An owner names a principal (a subject identity, a claim of operated-by or trusted, scopes, and a private label), signs the delegation as EIP-712, and H-Cert verifies the signature before anything is stored.
• On-chain commitments. Each vouch and revocation anchors to the standing topic (0.0.10601816) as a salted commitment: a hash of each identity with a fresh per-record salt. The public record proves a vouch is owner-signed and intact without revealing who is named.
• Behavior-backed standing. A decayed risk load, folded from risk events across the suite plus H-Seal receipts and H-Scope posture, sets a subject’s standing tier. It lowers the tier while risk is recent and recovers as risk decays. Fail-soft; it can only cap down, never revoke.
• Advisory by design. A consumer such as H-Grant or H-Pact resolves the directory and gates on the standing tier at its own trust boundary. H-Cert holds no credentials and no money; it only vouches.
• Public proof, private label. Anyone can verify a vouch is intact from the chain; only the owner and an auditor they disclose to can read who is named.

Using it from the showroom

The showroom is at h-series.xr-utilities.com/cert. The landing page is your directory.

1. Connect an EVM wallet. Your signature is what authorizes every delegation.
2. Name a principal. Onboard a grantee: the subject identity, a claim (operated-by for your own agents, trusted for a counterparty you vouch for), the scopes, and a private label that never leaves your directory.
3. Sign the delegation. You sign it as EIP-712 typed data. H-Cert verifies the signature against you, then anchors the salted commitment on Hedera.
4. Read your roster. Watch your resolved directory and each principal’s standing tier through the authenticated owner view.
5. Revoke when it changes. Revocation is owner-signed and terminal; sign it to retire a vouch.

To hand an auditor proof, disclose the identity and per-record salt: the auditor recomputes the commitment and matches it against the immutable on-chain record, no service secret involved.

Using it from an agent (the backend)

The backend is at h-cert.xr-utilities.ai. An agent does not build a directory; it reads standing and resolves whether a principal meets a bar.

1. The owner onboards the principal (once, from the showroom or a signed POST /principals call with the EIP-712 delegation and label).
2. A consumer resolves the principal against a requirement, or reads the standing directly.

GET  https://h-cert.xr-utilities.ai/standing/<subject>
  -> 200 { "subject": "...", "tier": "...", "operatorSignature": "..." }

GET /config returns the ruleset version, the standing topic id (0.0.10601816), the read mode, the operator verdict-signing public key, and whether anchoring is enabled. GET /verdict/:subject reads the cached, anchored standing verdict (404 when there is none). Agents that prefer a tool interface can resolve a directory and read standing through the H-Series MCP passthrough at https://mcp.xr-utilities.ai/mcp under the h_cert_* namespace, without a separate client.

Resolving a subject against requirements

POST /resolve is the access-decision seam a consumer (H-Grant or H-Pact) uses to ask whether a subject clears a bar. It composes the two H-Cert vouches, fail-closed: the behavior-derived STANDING verdict and the owner DELEGATION from the directory. ok is the conjunction of every requirement present; a requirement is only enforced when supplied.

The requirements object accepts minStanding (trusted | watch | unrated | suspended | revoked), maxStalenessSec (max age of the standing verdict in seconds), externalBadges (a string array of required badge ids), and delegation ({ delegatedBy: <owner CAIP-10>, scope?: <string> }, which requires a live, active, unexpired owner-to-subject delegation covering the scope). It returns { ok, standing, externalBadges, reasons, failClosed, delegation, sanctions }. A subject on the OFAC SDN list fails ok unconditionally regardless of the other requirements.

POST /resolve is sister-key S2S gated: it is inert until the calling service is registered as a trusted sibling (SISTER_PUBKEY_<id>), so only H-Grant or H-Pact drives an access decision. A normal caller or agent without a registered sister key gets a refusal, not a resolution. Present the ed25519 sister signature in X-Sister-Id / X-Sister-Ts / X-Sister-Sig (the signature is over ts\nmethod\npath\nsha256(body), within a 120-second freshness window).

POST https://h-cert.xr-utilities.ai/resolve
  Content-Type: application/json
  X-Sister-Id: <registered sibling id>
  X-Sister-Ts: <unix ts>
  X-Sister-Sig: <ed25519 signature over ts\nPOST\n/resolve\nsha256(body)>
  { "subject": "<subject>", "requirements": { "minStanding": "watch" } }
  -> 200 { "ok": ..., "standing": {...}, "reasons": [...], "failClosed": ..., "delegation": ..., "sanctions": {...} }
  -> 401 with no sister signature (unauthenticated); the route is inert to a normal caller

Reading through the MCP passthrough

The H-Series MCP passthrough at https://mcp.xr-utilities.ai/mcp exposes four free H-Cert read tools an agent can call without a separate client:

• h_cert_standing reads the current signed standing verdict for a subject (the tier, rank, ruleset version, evidence, asOf, operator signature, and the advisory sanctions block). Maps to GET /standing/:subject.
• h_cert_resolve resolves a subject against a requirements object (the same minStanding / maxStalenessSec / externalBadges / delegation fields as the route above). Maps to POST /resolve.
• h_cert_principals lists an owner’s roster. Maps to GET /principals.
• h_cert_config returns the standing topic id, ruleset version, read mode, operator key id, and anchoring state. Maps to GET /config.

Two of these carry the same gates as the underlying routes, so the tool call is not a bypass. h_cert_resolve targets the sister-key-gated /resolve, so an agent without a registered sister key gets the refusal, not a resolution. h_cert_principals targets the owner-authenticated /principals, but the tool sends no X-Owner-Proof header, so it returns 401 for a private roster; to read a roster you own, call GET /principals directly with the X-Owner-Proof proof described above.

Reading a roster you own

The roster and single-card reads are owner-authenticated: they return a private list of the subjects you have onboarded (as salted commitments), so the owner query param alone is not trusted. Sign a self-scoped delegation over your own identity (owner == subject), base64url-JSON encode it, and present it in the X-Owner-Proof header. H-Cert verifies it with the same per-namespace scheme as a write.

GET https://h-cert.xr-utilities.ai/principals?owner=<owner>
  X-Owner-Proof: <base64url JSON of a self-scoped delegation>
  -> 200 { "owner": "...", "principals": [ ... ] }
  -> 401 if no proof; 403 if the proof owner does not match ?owner=

Reading one principal’s card

To read a single principal instead of the whole roster, hit the same route with the subject in the path. It is owner-authenticated by the identical X-Owner-Proof self-scoped delegation as the roster read (owner == subject, base64url-JSON), and ?owner=<id> is still required. It returns that one principal’s card (the private label, the signed delegation, and the current standing tier), or 404 when the owner has no such subject.

GET https://h-cert.xr-utilities.ai/principals/<subject>?owner=<owner>
  X-Owner-Proof: <base64url JSON of a self-scoped delegation>
  -> 200 { ... one principal card (label, delegation, standing) ... }
  -> 401 if no proof; 403 if the proof owner does not match ?owner=; 404 if no such principal

Revoking a delegation (agent path)

Revocation is owner-signed and terminal. The showroom offers it as a one-click step; from an agent or the API, sign a delegation whose subject is the one you are retiring and POST it to the subject’s revoke route. The route subject must match the delegation subject (a mismatch is refused 400, no cross-subject revoke). H-Cert verifies the owner signature, anchors the new (revoked) state on the standing topic, and returns the updated card. Revoke is free (no x402 fee).

POST https://h-cert.xr-utilities.ai/principals/<subject>/revoke
  Content-Type: application/json
  { "delegation": { ... owner-signed delegation, subject == <subject> ... } }
  -> 200 { ... updated card (now revoked) ... }
  -> 400 if the delegation subject does not match the route
  -> 401/403 if the owner signature is absent, invalid, or not the delegating owner

Paying the write fee (agent path)

The two CREATE writes (onboard a principal, link an account) cost a one-time $0.10 over x402 on the agent path. Onboarding from the showroom and internal sibling calls over the sister-key channel are free. On the paid path:

1. Call the write with no payment. H-Cert answers 402 with an x402 payment challenge (stablecoin rails only under the default STABLECOIN_ONLY posture).
2. Present the signed payment in the X-PAYMENT header. H-Cert verifies it without moving money, performs the write (which anchors on chain), and captures the payment only on a successful anchor. A rejected write never charges the payer.

The paid path fails closed (503) when no payment rail or datastore is configured; the free sister-key path is unaffected. H-Cert holds no credentials and no money beyond the write fee, so there is no balance to withdraw and no treasury account to manage on the customer side.

Linking your identities under one account

An owner who holds several identities (an EVM wallet, a Hedera account, an OIDC login) can bind them under one account so a single login resolves the set.

• POST /account/link creates a mutually-proven link: an anchor proof and a member proof, each signed by its endpoint. Paid CREATE write ($0.10 x402 on the agent path; free from the showroom or the sister-key channel).
• POST /account/resolve returns the linked identifier set to a caller who proves control of one member. It is authenticated (the set is a private correlation), never a public read.
• POST /account/unlink dissolves a link; either endpoint signs a revoked proof. Free.

The account never signs and is never the on-chain subject; the link reuses the H-Cert delegation crypto with the claim account-link.

Re-anchoring a verdict (ops)

Standing recomputes live on every GET /standing/:subject read, so a consumer always sees current standing without any action. POST /refresh/:subject is the separate write that re-anchors a subject’s verdict to the standing topic when it has changed (anchor-on-change: it only writes on a real tier or evidence change, otherwise it is a no-op). It returns { changed, verdict }.

Refresh is sister-key S2S gated (the same ed25519 X-Sister-Id / X-Sister-Ts / X-Sister-Sig scheme as /resolve, empty body) and fail-closed, so it is driven on a cadence by the operator or a trusted sibling, not by a customer. There is nothing for an owner to call here: your subjects’ standing stays current on read, and the anchored copy is refreshed for you.

Sanctions overlay

A standing read also carries an advisory OFAC check. GET /standing and /verdict attach a separate sanctions block ({ listed, list: "ofac-sdn", effectiveTier: "revoked", advisory: true }); a subject on the US-Treasury OFAC SDN list reads sanctions.effectiveTier: "revoked" while the signed behavioral verdict itself is unchanged and still verifiable. POST /resolve refuses a sanctioned subject unconditionally. This is read-time and never anchored (OFAC is a public, mutable list, so anchoring it would be a staleness liability); the list is embedded and refreshed weekly from the public OFAC source. It is the advisory standing mirror of the hard money-path deny in H-Agent, which refuses to pay a sanctioned counterparty before any funds move.

Audit export (selective disclosure)

An owner can hand an auditor proof that a delegation is intact and owner-signed, without ever disclosing a private key or a service secret. The export returns a principal’s raw identity plus its per-record salt; the auditor recomputes the salted commitment hash and matches it against the immutable on-chain record on the standing topic. If the hashes match, the delegation is proven exactly as anchored.

The check is keyless and verifiable after the fact: the auditor needs nothing from H-Cert beyond the disclosed identity and salt, and the on-chain record is readable from any mirror node.

POST https://h-cert.xr-utilities.ai/principals/<subject>/disclose
  -> 200 { "subject": "...", "salt": "...",
           "commitment": "<recomputed hash>", "anchorRef": "..." }

The disclose route is owner-signed for the (owner, subject) pair, and the subject must match the route.

Where to go next

• Build your directory from the showroom at h-series.xr-utilities.com/cert.
• For the exact endpoints, the delegation schema, and the standing ruleset, see the H-Cert reference.
• Standing consumes behavior from H-Scope, H-Gate, and the rest of the suite, and gates release in H-Grant. See how the loop closes in Start here.