H-Pact: signed on-chain membership rings

H-Pact is the membership layer of the H-Series. It records which agents, MCP servers, and API services have agreed to operate together as a ring: a bounded set of CAIP-10 identities governed under shared, owner-signed rules. It is a twin of H-Index, a registry of relationships rather than capabilities. Every membership change is signed by the governing authority and anchored on Hedera Consensus Service as a salted commitment, so the public can verify the set without reading who is in it.

What it does

• Owner-signed governance. Create, admit, evict, update policy, renew, and retire are each authorized by an owner signature (TIP-712 / EIP-712 / Ed25519, CAIP-10 identity), never a console toggle. There is no operator override.
• Private membership, public proof. The ring stores salted commitments (hash(identity, salt)) on chain, not identities. Anyone can verify the set is legitimate and complete; only members read the resolved roster over an authenticated channel.
• Standing. Each member carries a standing: active, probation, suspended (reversible, access withheld), or evicted (terminal removal).
• Terminal closure. Retire closes a ring permanently; it accepts no further events and drops out of discovery, while its signed history stays on chain.
• Reconstructible. The local index is a derivable cache over the HCS topic. A full rebuild runs from chain, so the on-chain record is the source of truth.

Using it from the showroom

The showroom is at h-series.xr-utilities.com/pact. It is for a person creating and governing a ring.

1. Sign in. Connect a wallet or sign in with Google. Your signature (or session) is what authorizes every ring event.
2. Create a ring. Use the “Create a ring” action. Set the governance mode (single-owner in v1) and the initial policy, then pay the $5.00 creation fee over x402 in a stablecoin: USDC on Hedera, Base, Solana, or Stellar, or RLUSD on XRPL. The signed ring.create event is anchored on the HCS topic, permanent.
3. Admit members. Add each member by its CAIP-10 identity. The admit is owner-signed and free; on chain it is recorded as a salted commitment, not the raw identity. Admit one at a time or in a batch.
4. Govern. Evict a member, update the policy version, or renew a member’s expiry. Every action is owner-signed and free.
5. Retire when done. A retire closes the ring permanently. It is irreversible, so the record of the relationship remains verifiable after the ring is closed.

Using it from an agent (the backend)

The backend is at h-pact.xr-utilities.ai. All endpoints return JSON. Ring writes require a structured-data signature and, for creation only, an x402 payment header. Read endpoints are unauthenticated except the resolved roster, which is served over the authenticated member channel.

POST https://h-pact.xr-utilities.ai/rings
  X-Payment: <x402 envelope (base64)>
  Content-Type: application/json
  {
    "governanceMode": "single-owner",
    "policy": "",
    "ownerAccountId": "<CAIP-10>",
    "ringTopicId": "0.0.10587224",
    "issuedAt": 1718000000,
    "signature": "<structured-data signature>"
  }
  -> 201 { "ringId": "0.0.10587224/<seq>", "consensusTimestamp": "...", "paymentTxId": "..." }

POST https://h-pact.xr-utilities.ai/rings/:ringId/admit         (owner-signed, free)
POST https://h-pact.xr-utilities.ai/rings/:ringId/admit-batch   (owner-signed, free, up to 50)
POST https://h-pact.xr-utilities.ai/rings/:ringId/evict         (owner-signed, free)
POST https://h-pact.xr-utilities.ai/rings/:ringId/policy        (owner-signed, free)
POST https://h-pact.xr-utilities.ai/rings/:ringId/renew         (owner-signed, free)
POST https://h-pact.xr-utilities.ai/rings/:ringId/retire        (owner-signed, free, terminal)

GET  https://h-pact.xr-utilities.ai/rings/:ringId               (public metadata, no identities)
GET  https://h-pact.xr-utilities.ai/rings/:ringId/check?identity=<caip10>  (sister-key auth)
GET  https://h-pact.xr-utilities.ai/rings/:ringId/members       (sister-key auth; roster)
GET  https://h-pact.xr-utilities.ai/config                      (topic id, modes, roles, pricing)

Every write authorizes with exactly one of signature (wallet path) or ownerOidc (enterprise OIDC path, off by default). A create request without payment returns 402 Payment Required with a payment options envelope; the client selects a method, constructs a signed transfer, and resubmits with the base64 x402 envelope in X-Payment. Signatures carry a 300-second freshness window and a single-use replay lock, so a signed event cannot be replayed. GET /rings/:ringId is public and returns the ring’s state (owner, governance mode, policy version, size, status, and the read-only narrative) without revealing membership.

Admit members (one or many)

• One member: POST /rings/:ringId/admit with ringId, memberIdentity (CAIP-10), an optional role (default member), an optional expiresAt, and the owner authorization fields. The per-entry salt is generated server-side when omitted; the on-chain record is the salted commitment, not the raw identity.
• Many members: POST /rings/:ringId/admit-batch with a members array (up to 50 entries, each a memberIdentity and optional salt), one role, and one owner signature over the member-set hash. One on-chain event admits the whole batch.

Check membership (agent gate)

GET /rings/:ringId/check?identity=<caip10> returns { member, standing } and is the hot path a consumer calls on every interaction. It is authenticated over the ed25519 sister-key service-to-service channel (not a public oracle), so a registered sister service (H-Relay, H-Grant, H-Index) signs each request; anyone else gets 401. Treat any standing other than active as access-withheld.

Read the resolved roster (owner only)

GET /rings/:ringId/members returns each member’s commitment, role, and standing to any registered sister caller. Raw CAIP-10 identities are disclosed only when the caller proves it is the ring owner, either with a per-read owner signature (X-Owner-Account / X-Owner-Issued-At / X-Owner-Sig) or a wallet SSO session (X-Wallet-Authorization) that recovers to the owner. The response carries identitiesDisclosed so a caller knows whether it got the resolved roster or commitments only.

Agents that prefer a tool interface reach the same capability through the shared H-Series MCP server at https://mcp.xr-utilities.ai/mcp under the h_pact_* namespace. For the exact payloads and signing envelope, see the H-Pact reference.

Member standing

Each member carries a standing that governs whether it is treated as in good standing:

• active. Admitted and in good standing.
• probation. Admitted but watched.
• suspended. Auto-demoted and reversible, with access withheld. A member drops here without an explicit event, for example when an H-Scope posture drop demotes it or its membership expires (an expired membership reads as suspended without an explicit evict).
• evicted. Terminal removal.

Tool-scope policy

A ring’s policy can declare a tool scope: a named MCP service plus a subset of its tools. On H-Pact this is descriptive audit only, surfaced on the ring detail read (toolScope, enforced:false); the ring defines what is in scope, but H-Pact does not enforce it. Enforcement is the owner-signed grant in H-Grant (which caps per counterparty), and H-Agent enforces the cap at runtime.

Enterprise (OIDC) rings

A ring can be owned by an enterprise OIDC identity with no wallet (oidc:<iss>:<sub>), enabled by the identity bridge. The owner still signs every ring event (admit, evict, renew, retire) with their token; no operator step is involved. Because the keyless HCS topic cannot anchor a token, H-Pact co-signs each OIDC event with its operator key to root replay proof. The trade-off is scoped to OIDC rings only: a wallet-owned ring is fully self-sovereign (it depends on neither the service nor the operator key), while an OIDC ring depends on the service running to act and on the operator key for replay proof.

Payment and refunds

H-Pact never custodies funds; there is no wallet or held balance to withdraw. The only paid action is ring creation, and it uses two-phase settlement: the $5.00 fee is captured only after the ring is anchored on chain, so a failed create never charges you (deferred rails do not capture; already-moved rails refund). If a legacy create (from the old settle-first flow) settled but its write failed, the transaction is held as a durable, single-use credit; the same owner’s retry of the same create at the same price claims it automatically and skips the payment leg, so a create is never charged twice. An explicit monetary refund is a manual operator request (xr-utilities@proton.me).

Where to go next

• Create your first ring at h-series.xr-utilities.com/pact.
• See how H-Pact composes with the rest of the suite in Start here.