Compose the ecosystem

Start here is the five-minute overview: what each product is and how the lifecycle fits together. This article is the hands-on version. It follows one realistic agent run from end to end and, at each step, names what actually moves between the products: which identity, which signature, which payment, which reference.

The scenario

An owner (a person, or a business) wants an agent to do a small piece of paid work on their behalf: find a service that does invoice extraction, hire it, run one invoice through it, and keep proof. The owner wants the agent to spend real money but only within a cap, wants the run to be provable afterward, and does not want a raw API key or a customer’s data leaking out of the boundary.

Every product below plays one part. The point of the walkthrough is the seams: the exact hand-off from one product to the next.

Step 1: discover the service (H-Index)

The owner (or the agent, through the Console) searches H-Index for an invoice-extraction service.

• Showroom: https://h-series.xr-utilities.com/registry/browse
• Agent API: https://h-index.xr-utilities.ai
• MCP: https://mcp.xr-utilities.ai/mcp under h_index_search

H-Index is a registry over agents, tools, and MCP servers. A search returns candidate listings, each carrying a trust label: whether the listing is owner-signed and paid (attested), whether the owner proved control of the host (verified owner), and derived safety flags (a known vulnerability in the manifest, capability drift since it was registered, a rug-pull signal). It also carries a receiptAnchoring badge that says whether the provider is actively anchoring proof-of-execution receipts.

What comes out of this step: the chosen service’s endpoint URL, its owner identity, and its advertised capability surface (its MCP tools/list). That endpoint URL and owner identity are the inputs to the next step.

H-Index only tells you what is out there and how trustworthy it looks. It does not hold authority, take custody, or move the agent’s money. That is deliberate: discovery is a separate concern from authority.

Step 2: give the agent a runtime identity and a spend cap (H-Agent)

Before the agent can pay for anything, it needs an identity it holds and a hard ceiling on what it can spend.

• Showroom: https://h-series.xr-utilities.com/agent
• Agent API: https://h-agent.xr-utilities.ai

The owner signs in (Google or a wallet), and H-Agent mints the agent an MPC-held Coinbase CDP wallet. The key lives in a Trusted Execution Environment held by Coinbase CDP; H-Agent never holds it and takes no custody of the funds. Provisioning mints identity only: the agent can spend nothing until a cap is materialized from an H-Grant grant (apply-grant). The cap is then a CDP Spend Permission: an owner-signed, on-chain USDC allowance on Base, enforced by the Spend Permission Manager contract. An over-cap payment reverts on chain. The cap is not a suggestion H-Agent honors; it is a contract.

What flows in: the owner’s identity and a signed cap amount and rate. What flows out: the agent’s CAIP-10 identity (eip155:8453:0x...) and an MCP connection string the owner pastes into their agent runtime (for example, Claude). From here the agent can answer “who am I”, “how much cap do I have left”, and “pay”, all within the signed limit.

This is the identity the agent carries into every subsequent step. H-Index knew the agent by nothing; from now on it acts as this account.

Step 3: grant capped authority over a credential the agent never sees (H-Grant)

The invoice service needs an API key. The owner does not want the agent to hold that key. This is what H-Grant is for.

• Showroom: https://h-series.xr-utilities.com/grant
• Agent API: https://h-grant.xr-utilities.ai

The owner deposits the credential into a vault, then signs a grant: a policy naming the grantee (the agent’s CAIP-10 identity from step 2), the allowed action and target, and hard caps on amount, count, and rate. The grant is anchored on chain. The credential is envelope-encrypted at rest and, in the production nitro mode (LIVE, cutover 2026-07-26), is decrypted and used only inside an AWS Nitro enclave whose attestation matches a pinned measurement; AWS KMS releases the data key only to that measured enclave, so even someone with full host access cannot read the credential. This is operator-zero-access, live in production. The Railway standby retains the software kms mode as an instant rollback.

When the agent needs the gated action, it calls H-Grant with the grant id and pays for the call over x402. H-Grant checks the grant is valid, not revoked, and within caps, releases the credential inside the boundary, performs the upstream call, and returns only the result plus a receipt reference. The secret is never in the request or the response.

What flows in: the agent’s identity (as grantee), the owner’s signed grant. What flows out: the result of the gated call and a receipt reference. The agent gained the power to use a credential without ever gaining the credential.

Note the difference from step 2. H-Agent caps what the agent can spend. H-Grant caps what the agent can do with a secret. They are orthogonal; a full run uses both.

Step 4: act and pay per call (x402, H-Relay)

Now the agent does the work. Each paid action rides x402: the agent presents a payment with the request, and the service being paid re-verifies settlement on chain. The facilitator is never trusted; the payment is payer-bound and replay-guarded, so the same payment cannot be reused. Payments settle in a stablecoin (USDC on Hedera, Base, Solana, or Stellar; RLUSD on XRPL).

If the work involves reaching another agent (delivering a task to a mailbox, checking whether a counterparty agent is live, or proxying context), that transport runs through H-Relay:

• Showroom: https://h-series.xr-utilities.com/relay
• Agent API: https://h-relay.xr-utilities.ai

H-Relay is the post office, not the registry: it delivers messages, carries a liveness heartbeat, and proxies context. It resolves addresses against H-Index but does not itself decide who is trustworthy.

What flows in: the agent’s identity, an x402 payment per action, and (for transport) the counterparty address resolved from H-Index. What flows out: the work product, and a settled on-chain payment each service can prove it received.

Step 5: prove what happened (H-Seal)

A paid call that leaves no trace is a dispute waiting to happen. H-Seal anchors a tamper-evident receipt of the run.

• Showroom: https://h-series.xr-utilities.com/seal
• Agent API: https://h-seal.xr-utilities.ai
• $0.05 per receipt; verification is free.

The caller builds a receipt (request and response hashes, both identities, timestamps, result), signs it with TIP-712 or EIP-712, and anchors it on Hedera Consensus Service with an x402 payment. A receipt can be caller-only (one signature) or co-signed by both sides (non-repudiable: neither party can later claim the call did not happen or that the request or response was different). Anyone can verify it against a Hedera mirror node with no account and no trust in the H-Series backend.

What flows in: the identities and content hashes from the run. What flows out: a receipt id and an on-chain reference. That reference is what H-Index reads back in step 1 as the provider’s receiptAnchoring signal, which is how proof feeds discovery: a provider that anchors receipts earns a badge the next searcher sees. The loop closes.

Step 6: guard against a bad counterparty and a data leak (H-Scope, H-Gate)

Two independent guards run around the work, not inside it.

H-Scope scores an on-chain entity at the moment a trust decision is made.

• Showroom: https://h-series.xr-utilities.com/scope
• Agent API: https://h-scope.xr-utilities.ai/scan

Given a CAIP-10 address (the service’s owner, say), H-Scope returns two orthogonal deterministic scores: an activity score (how automated and service-like the address behaves) and an entity posture (how institutionally established it is), each resolving to a named band with the contributing signals listed. It is a pure function of public chain data, so the same address yields the same scores, and it is a posture signal H-Grant can require as a condition on a grant. H-Scope does not enforce anything; it informs.

H-Gate inspects what the agent is about to send across a boundary.

• Showroom: https://h-series.xr-utilities.com/gate
• Agent API: https://h-gate.xr-utilities.ai
• Free in the showroom; $0.10 per inspection on the agent API.

A deterministic detector suite flags emails, cards, government ids, financial accounts, crypto addresses, provider tokens, secrets, keys, and PHI (pattern detectors plus checksum, entropy, and Luhn validation, no model in the trust path) and applies a policy: allow, redact, or block. Every paid redact or block anchors an H-Seal receipt (allow and the free showroom path do not). One honest caveat: the detection engine is enclave-safe by construction, but the production Nitro enclave is designed for and not yet deployed, so today it runs the engine in software. Treat H-Gate inspection as software-isolated, not hardware-isolated, until that enclave ships. This is not H-Grant’s posture: H-Grant’s credential custody runs the production nitro enclave LIVE (operator-zero-access), so the two are decoupled (H-Grant nitro-live, H-Gate software-isolated).

What flows in: a counterparty address (H-Scope) and a candidate payload (H-Gate). What flows out: an advisory posture band and an allow/redact/block decision with a receipt. Neither guard sits in the money path; both are checks the owner or the agent chooses to consult.

Standing over time (H-Cert)

Across many runs, the agent and its owner accrue standing. H-Cert is a directory of named principals with a behavior-backed standing tier, plus owner-to-agent delegation.

• Showroom: https://h-series.xr-utilities.com/cert
• Agent API: https://h-cert.xr-utilities.ai

H-Cert answers “who is this principal and how established is their behavior” as an advisory input that H-Grant or a counterparty can consult before extending authority. It issues standing; it does not enforce it. That advisory-not-enforcing posture is deliberate: enforcement lives in the on-chain caps (H-Agent’s Spend Permission, H-Grant’s grant), not in a reputation number.

How the seams actually fit

Reading the steps as one flow, the same three things move throughout:

• Identity is one CAIP-10 account. The agent minted in step 2 is the grantee in step 3, the payer in step 4, a receipt signer in step 5, and the subject of standing in H-Cert. No product re-issues identity; they all reference the one account.
• Authority is always an owner signature over structured data. The spend cap (H-Agent), the grant (H-Grant), the receipt (H-Seal), and every H-Index registration are owner-signed with TIP-712 / EIP-712 / Ed25519. No product widens authority with a toggle; a change requires a new signature.
• Payment is x402, re-verified by whoever is paid. Each backend prices and collects its own call independently. There is no shared wallet balance the products draw from; the agent pays each service, and each service proves settlement on chain for itself.

What deliberately does not flow between them is a shared session or a trusted intermediary. There is no single sign-on that grants blanket access across backends, and no product trusts another product’s word for a payment or an authority. Each call stands on its own signed authority and its own on-chain settlement. That is what lets you adopt one product without the others, and what keeps a compromise of one from cascading into the rest.

Where to go next

• The single-product guides under Services in the sidebar, each covering the showroom and the agent backend.
• The Console guide, the plain-language on-ramp that composes H-Index, H-Agent, H-Grant, x402, and H-Seal for you.
• The architecture overview for the trust model behind the seams.
• The frequently asked questions for cost, chains, safety, and support.