Wire Types
INK uses two distinct identifier formats for message types. Implementations MUST distinguish between them.
Convention
| Purpose | Format | Example |
|---|---|---|
| AT Protocol Lexicon ID | camelCase, includes ink segment | network.tulpa.ink.auditQuery |
Wire type field | snake_case, omits ink segment | network.tulpa.audit_query |
The lexicon ID follows AT Protocol conventions (camelCase NSID with hierarchical namespacing). The wire type is the value in the "type" field of a protocol message; it is what implementations match on when routing those messages. Intent messages are the exception: an intent envelope has no type field and carries the action in its intent field instead, even though intent is a registered suffix.
Implementations MUST key off the wire type field, not the lexicon ID.
Two prefixes, one registry
Every registered suffix has two equivalent spellings on receipt: the legacy network.tulpa.<suffix> and the vendor-neutral network.ink.<suffix>. The network.tulpa. prefix is a historical artifact of INK’s origin and does not imply Tulpa ownership.
Dual-accept rule, frozen for 1.0. A conforming receiver MUST accept both spellings of every registered suffix; network.ink.<suffix> validates wherever network.tulpa.<suffix> does. A sender MUST continue to emit network.tulpa.* by default, so a receiver that has not upgraded never sees the new prefix. Dual-accept is receiver-side leniency, independent of the signed protocol field, and is not gated on ink/0.2.
A validated message keeps the type string it arrived with. Every signature, hash, receipt and AEAD binding is over the spelling on the wire and never a normalized one, so relabelling a message fails verification.
Excluded from dual-accept. audit_response and audit_inclusion stay network.tulpa.* only. Each carries a detached signature that authenticates a payload subset and not the envelope type, so the relabel-rejection guarantee cannot hold for them. The vendor-neutral spelling is withheld until a future wire change brings type under their signature. Every other registered type either signs its full body or binds type into its AEAD additional authenticated data, so its dual-accept is relabel-safe.
A router built without dual-accept is not conformant. Build the dispatch table from the registry, not from this page.
Registered suffixes
The allocated suffixes and their vendor-neutral eligibility are registered in ink-protocol.md §6, which is the authority. It is the list to read when building a router; the table below is an orientation and the registry wins wherever they differ.
Wire Type (type field) | Lexicon ID | Description |
|---|---|---|
network.tulpa.intent | network.tulpa.ink.intent | Registered intent suffix (intent envelopes carry the intent field, not a type) |
network.tulpa.challenge | network.tulpa.ink.challenge | Handshake challenge |
network.tulpa.rejection | network.tulpa.ink.rejection | Handshake rejection |
network.tulpa.resolution | network.tulpa.ink.resolution | Handshake resolution |
network.tulpa.encrypted | network.tulpa.ink.encrypted | ECIES encrypted envelope |
network.tulpa.receipt | network.tulpa.ink.receipt | Delivery or disposition receipt |
network.tulpa.introduction_receipt | network.tulpa.ink.introductionReceipt | Introduction receipt |
network.tulpa.audit_query | network.tulpa.ink.auditQuery | Bilateral audit query |
network.tulpa.audit_response | network.tulpa.ink.auditResponse | Bilateral audit slice response. Tulpa spelling only |
network.tulpa.audit_query_response | network.tulpa.ink.auditQueryResponse | Witness audit-query response |
network.tulpa.audit_submit | network.tulpa.ink.auditSubmit | Witness submission |
network.tulpa.audit_inclusion | network.tulpa.ink.auditInclusion | Witness inclusion receipt. Tulpa spelling only |
network.tulpa.key_rotation | network.tulpa.ink.keyRotation | Key-rotation audit bridge |
network.tulpa.agent_card_query | network.tulpa.ink.agentCardQuery | Capability-gated card query |
network.tulpa.agent_card_response | network.tulpa.ink.agentCardResponse | Card query response |
network.tulpa.agent_card_denied | network.tulpa.ink.agentCardDenied | Card query denial |
network.tulpa.discovery_query | network.tulpa.ink.discoveryQuery | Directory discovery query |
network.tulpa.authorization_challenge | network.tulpa.ink.authorizationChallenge | Sign in with INK challenge |
network.tulpa.authorization_grant | network.tulpa.ink.authorizationGrant | Sign in with INK grant |
The delegation-chain types (network.ink.delegation_link and network.ink.authorization_chain) are defined only in the vendor-neutral spelling and have no legacy alias. See Authorization Chains.
Why Two Formats
For single-word types, the distinction is invisible: network.tulpa.challenge maps to network.tulpa.ink.challenge.
For multi-word types, it matters: network.tulpa.audit_query (wire) vs. network.tulpa.ink.auditQuery (lexicon).
The wire format uses snake_case for consistency with the JSON body convention. The lexicon format uses camelCase to match AT Protocol’s NSID registry convention.