Build on the ~alter stack
~alter is the identity layer. Your software is the client that reads identity on it. This guide walks the four moves an integration makes, in order: address a person with a ~handle and resolve it, read what they have consented to share over the Model Context Protocol (MCP), pay per query with x402 so the person earns when their data is used, and stay inside the consent boundary the whole way.
Each stage is a pointer into the reference pages that carry the full detail. If you have not set up an account and credentials yet, start with Getting started, then come back here.
Principles
Substrate observation
Why the rails carry no canonical narrative: every state-claim is observed from a substrate and carries provenance, and concurrent agents merge what they see locally. Read this before you reason about how concurrent reads stay coherent.
Before you start
Two endpoints carry everything below. The REST API serves accounts, credentials, and earnings; the MCP Identity Server serves agent-to-agent identity queries over JSON-RPC 2.0.
| REST base | https://mcp.truealter.com/api/v1 |
| MCP endpoint | https://mcp.truealter.com/api/v1/mcp |
| Transport | streamable-http (JSON-RPC 2.0) |
| Auth | Free tools work anonymously. A capability token from the OAuth connect flow, sent as a bearer credential, raises rate limits and reaches consent-gated tools. See Authentication. |
1. Resolve a ~handle
A ~handle is how one identity addresses another. Where @ answers where can I reach you, ~ answers who are you, verifiably. A domain-qualified handle resolves through a single DNS TXT lookup that advertises the org alter’s MCP endpoint and signing key.
# Discover the org alter behind a domain-qualified handle
dig +short TXT _alter.truealter.com
"v=alter1; mcp=https://mcp.truealter.com/api/v1/mcp; pk=ed25519:BASE64URL_ORG_PUBKEY"From there, an MCP client connects to the advertised endpoint and calls alter_resolve_handle, which returns a signed identity card. The grammar, the three resolution paths, the card schema, and a minimal client live in the ~handle protocol reference.
2. Read identity over MCP
Any MCP-compatible client connects to the identity server in one step, then calls tools/list to discover what it can read and tools/call to read it. Free tools such as verify_identity and get_profile need no payment.
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "verify_identity",
"arguments": {
"member_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}
}
}The connection handshake, the tier table, and the full tool catalogue are in the MCP Identity Server reference.
3. Pay per query with x402
Paid reads, such as a full trait vector, are gated by x402. The server answers an unpaid call with HTTP 402 and machine-readable pricing; the client pays and resubmits with a _payment object. Each verified identity starts with a one-time free allowance, sized to its tier, that does not renew: a free read still earns the person recognition, but only a paid read earns Identity Income. Of every payment, 75% goes to the person whose identity data was read.
// A paid call with no payment returns a payment-required
// tool result with machine-readable pricing in _meta.x402
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"content": [{
"type": "text",
"text": "This identity data has a price set by its owner, not its platform. Tool 'get_full_trait_vector': $0.10 USD. ..."
}],
"isError": true,
"_meta": {
"x402": {
"version": "1.0",
"request_id": "req_5f2a9c1b3d4e6f7a8b9c0d1e",
"tool": "get_full_trait_vector",
"tier": 2,
"price": "0.1",
"amount_usdc": "0.1",
"amount_usdc_raw": 100000,
"currency": "USD",
"accepted_assets": ["USDC"],
"accepted_networks": ["base", "base-sepolia"],
"chain": "base",
"chain_id": 8453,
"contract": "0x...",
"usdc_address": "0x...",
"facilitator_url": "",
"payee_address": "0x...",
"member_share": 0.75,
"method": "routePayment(uint8,address,bytes32)"
}
}
}
}The full four-step negotiation, the per-tool price table, and the Identity Income split are in the x402 reference.
4. Stay inside consent
Consent is enforced at every layer, and payment does not buy past it. A person progresses through four engagement levels (Explorer, Learner, Augmented, Deployed) and sets per-category consent at Learner and above. A read for a category the person has not granted is refused, and no payment is charged for a refused request.
// A read for an ungranted category is refused, even with valid payment
{
"jsonrpc": "2.0",
"id": 4,
"error": {
"code": -32002,
"message": "The target member has not granted your caller tier permission for this query.",
"data": {
"error_code": "consent_denied",
"http_status": 403
}
}
}Engagement levels, consent categories, withdrawal behaviour, and the credential surface are in the consent model and verifiable credentials.
Put it together
A working integration runs the four moves end to end: resolve the handle to find the org alter and the person, read the free identity surface over MCP, escalate to a paid read with x402 when you need depth, and let the consent layer decide what comes back. The reference pages below carry every detail; the protocol drafts beneath them carry the wire-level behaviour.
Foundations: the protocol stack
The wire-level behaviour behind ~handle addressing, discovery, agreements, and provenance is written in the open. An identity layer is only as trustworthy as the standards it rests on, so each piece is published as an individual Internet-Draft anyone can read, implement, and challenge.
Every document below is an individual Internet-Draft. None is endorsed by the IETF, adopted by a working group, or published as an RFC; none carries formal standing in the standards process. The drafts hold the normative behaviour. This page is the map.
A machine-readable copy of this index is served at /docs/protocol.md.
Identity addressing
How an identity is named and referenced.
- draft-morrison-alter-uri-schemeActive I-D
The 'alter' URI Scheme for Dispatchable ~handle References
A URI scheme so a ~handle reference can be resolved and acted on as a link.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
- draft-morrison-identity-pronounsActive I-D
Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems
A reference-axis grammar that sits orthogonal to the ~handle tier taxonomy.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Discovery
How an agent finds the identity surface.
- draft-morrison-mcp-dns-discoveryActive I-D
Discovery of Model Context Protocol Servers via DNS TXT Records
Discover Model Context Protocol servers through DNS TXT records.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
An IANA Registry for Model Context Protocol Tool Surface Names
A proposed IANA registry for naming MCP tool surfaces.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Agreements and attribution
How principals agree, and how work is attributed.
- draft-morrison-identity-accordActive I-D
Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals
A peer ceremony for reaching a bilateral agreement between two identity-bound principals.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Identity-Attributed Git Commits via Tier-Structured Trailers
Tier-structured git trailers that attribute a commit to a handle and the instrument that drafted it.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
- draft-morrison-reviewed-by-trailerActive I-D
Reviewed-By Trailer: Sovereign-Portable Peer-Review Attribution for Content-Hash-Bound Artefacts
A portable trailer that attributes a peer review to the artefact it reviewed.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Coordination and delivery
How concurrent sessions coordinate and how decisions reach a principal.
- draft-morrison-substrate-observationActive I-D
Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions
Coordinating concurrent sessions by observing the substrate rather than exchanging coordination envelopes.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
- draft-morrison-agent-channel-fan-outActive I-D
An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions
An identity-keyed frame for fanning a delivery out to concurrent sessions.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
- draft-morrison-binding-moment-envelopeActive I-D
The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation
A delivery contract for an agent-to-principal decision moment, with a dual-veto reconciliation.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Provenance and governance
How inference location, output provenance, and inherited policy are made legible.
- draft-morrison-compute-location-gateActive I-D
The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes
Negotiating where an identity inference computes, at the wire layer before any inference runs, as a function of the input's provenance class.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Substrate-Provenance Annotation Grammar for Large-Language-Model Output
An annotation grammar for tagging language-model output with its provenance.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Policy Provision and Governance Inheritance from an Organisational Identity Substrate
Provisioning policy and inheriting governance from an organisational identity substrate.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
- draft-morrison-consent-settlementActive I-D
Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments
Binding a paid identity read to the subject's recorded consent and settling a share of the price to that subject.
Internet-Draft (individual submission): active, not WG-adopted, not an RFC, no formal IETF standing.
Status reflects the IETF datatracker as observed on the date above. Internet-Drafts expire six months after posting. Follow each datatracker link for the current revision and state.
Observed 2026-06-01.