Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-14 · Instrument version 1.0.0
What Matters
Preserve the scope with the word. A payment authorization is not a captured payment; an order acknowledgement is not a fill; a token can be a card credential or a programmable asset. This glossary defines forty terms in twenty pairs, with primary documentation, stable IDs and a downloadable record of the meaning you intend to use.
A decision can become unreliable before any calculation begins: the people or systems involved may be using the same word for different things. “Verified” can describe a checked authorization rather than a completed payment. “Agent” can describe a model-directed process without establishing its authority to spend. “Final” can refer to a chain state rather than a successful commercial outcome.
This reference keeps those distinctions visible. Each definition names its scope: a protocol version, an API, a provider’s terminology or a clearly attributed conceptual source. It is organized as paired meanings because the practical problem is often substitution. A familiar label gets carried into a document where it no longer supports the intended claim.
Use the stable term ID when citing or exchanging a definition. The record tool below carries the wording, source, review date and your declared context into JSON. It records what you mean; it does not inspect an integration or turn a declaration into verification.
DN Evidence Block
Sources reviewed: 2026-11-14 · Evidence type: Primary specifications, official implementation documentation and originating-organization definitions opened on 13 November UTC / 14 November Africa/Johannesburg.
Scope: Forty definitions in twenty contrast pairs, edition 1.0.0. MCP terms use specification 2026-07-28, AP2 terms use v0.2 and x402 terms use v2. Other sources retain the named implementation and the check date.
- Every definition has its own stable term ID and a directly linked primary source.
- The pairs distinguish terms across protocol, payment, execution, identity and monetary contexts.
- KYA is defined through a named vendor framework; it is not presented as a universally standardized legal regime.
- The included scope-record examples are synthetic selections. They are not observed implementations or product tests.
Not established by this work: No supplier conformance, integration reliability, investment quality, legal classification or account eligibility is independently certified by this glossary.
Original DN instrument · version 1.0.0
DN Term Scope Record
Select a term pair and export the exact definitions, stable IDs, source links and scope used in this edition. Record your application context without treating your declaration as independent verification.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
A versioned reference lookup and user-entered scope record. It does not classify free text, inspect documents, test implementations, determine legal obligations or certify that a term has one universal meaning. Source URLs may change; the retained definitions and review dates describe this edition.
1. AI agent / Workflow
AI agent. In Anthropic’s architectural taxonomy, a system in which an LLM determines its next steps and tool use while pursuing a task. [1]
Anthropic’s December 2024 architecture taxonomy. Stable ID: DN-TERM-001.
Workflow. In the same taxonomy, a system whose sequence of LLM and tool operations follows paths specified in code. [1]
The paired Anthropic architecture definition. Stable ID: DN-TERM-002.
Keep the distinction: An agent can operate inside a larger workflow. The label alone says little about reliability, spending authority or how much human supervision the implementation requires.
Ask before using the term: Which decisions are fixed in code, and which decisions does the model make?
2. Model Context Protocol (MCP) / Agent2Agent (A2A)
Model Context Protocol (MCP). A protocol through which an AI application connects to external context and capabilities exposed by servers. [2]
MCP specification 2026-07-28. Stable ID: DN-TERM-003.
Agent2Agent (A2A). A protocol for clients and remote agents to exchange messages, coordinate work and receive results without exposing the remote agent’s internal implementation. [3]
A2A core concepts reviewed for this edition. Stable ID: DN-TERM-004.
Keep the distinction: A connected tool and a delegated remote task occupy different roles. A product can use both protocols; supporting either does not establish the other’s behavior.
Ask before using the term: Are you invoking a capability or handing work to another agent?
3. MCP tool / MCP resource
MCP tool. A named callable capability exposed by an MCP server, with an input definition and a result returned when invoked. [4]
MCP 2026-07-28 server tools. Stable ID: DN-TERM-005.
MCP resource. Context data identified by a URI and exposed by an MCP server for a client to read or incorporate into an application. [5]
MCP 2026-07-28 server resources. Stable ID: DN-TERM-006.
Keep the distinction: Reading a resource and invoking a tool are different protocol operations. Either may contain untrusted material. Neither name establishes permission to carry out a financial action.
Ask before using the term: Does the integration need context data, a callable action or both?
4. MCP prompt template / Agent Skill
MCP prompt template. A server-provided set of structured messages or instructions that a client can discover and retrieve, potentially supplying arguments. [6]
MCP 2026-07-28 server prompts. Stable ID: DN-TERM-007.
Agent Skill. A portable folder containing a SKILL.md definition and optional supporting scripts, references or assets that an agent can load for a task. [7]
Agent Skills format, reviewed documentation. Stable ID: DN-TERM-008.
Keep the distinction: A prompt is a protocol-exposed template; a skill is a packaged capability description and supporting material. Packaging a skill does not make its instructions authoritative or its scripts safe.
Ask before using the term: Are you distributing a discoverable prompt or a portable folder of task instructions and resources?
5. A2A task / A2A artifact
A2A task. A stateful unit of work with an identifier and lifecycle through which a remote agent reports progress or completion. [3]
A2A task model. Stable ID: DN-TERM-009.
A2A artifact. A concrete output produced during an A2A task, such as a document or structured data, with its own artifact identifier and content parts. [3]
A2A artifact model. Stable ID: DN-TERM-010.
Keep the distinction: Task state tracks work; an artifact carries a result. A completed task does not independently prove that its output is correct.
Ask before using the term: Do you need the work’s status or the actual deliverable?
6. Authentication / Access authorization
Authentication. Checking the claimed identity of a user, service or other entity through an applicable identity mechanism. [8]
OWASP access-control terminology. Stable ID: DN-TERM-011.
Access authorization. Deciding whether an identified or otherwise qualifying entity may perform a particular action on a particular resource. [8]
OWASP access-control terminology; separate from card-payment authorization. Stable ID: DN-TERM-012.
Keep the distinction: Successful sign-in does not grant every permission. Keep identity evidence separate from the action, resource and conditions covered by the access decision.
Ask before using the term: Which identity was established, and what exact action was allowed?
7. Checkout Mandate / Payment Mandate
Checkout Mandate. AP2’s cryptographic authorization evidence showing that the shopping agent may purchase the checkout it assembled, supplied to and verified by the merchant. [9]
AP2 v0.2 specification. Stable ID: DN-TERM-013.
Payment Mandate. AP2’s mandate authorizing payment for a particular checkout, verified by the relevant credential and payment participants. [10]
AP2 v0.2 Payment Mandate. Stable ID: DN-TERM-014.
Keep the distinction: The purchase and its payment have linked but different authorization records. This edition uses the v0.2 terms; older AP2 examples may use Intent Mandate or Cart Mandate.
Ask before using the term: Which protocol version applies, and does the record authorize the checkout, the payment or both?
8. UCP checkout / UCP order
UCP checkout. A commerce capability and stateful checkout entity that collects and validates purchase details before completion and order creation. [11]
UCP Shopping Checkout specification, reviewed edition. Stable ID: DN-TERM-015.
UCP order. A current-state record of an order, linking back to its checkout and describing fulfillment, adjustments and relevant totals. [12]
UCP Shopping Order specification, reviewed edition. Stable ID: DN-TERM-016.
Keep the distinction: Checkout readiness, completion in progress and a completed order are different states. An order record also does not mean that every item has been delivered.
Ask before using the term: Is this still a checkout, an accepted completion request or an order with fulfillment evidence?
9. HTTP 402 / x402 PaymentPayload
HTTP 402. The HTTP status named Payment Required; RFC 9110 reserves it for future use rather than defining a complete payment method. [13]
Base HTTP semantics, RFC 9110 section 15.5.3. Stable ID: DN-TERM-017.
x402 PaymentPayload. The client’s structured payment-authorization payload, carrying accepted requirements and scheme-specific data for the x402 payment flow. [14]
x402 specification v2. Stable ID: DN-TERM-018.
Keep the distinction: A status code and a payment payload are different objects. Neither, by itself, is evidence that funds settled or a paid service produced the requested output.
Ask before using the term: Which payment specification and state are present beyond the HTTP code?
10. x402 verification / x402 settlement
x402 verification. Validation of payment authorization without committing payment state or writing on-chain state through the protocol’s read-only verify operation. [14]
x402 v2 /verify semantics. Stable ID: DN-TERM-019.
x402 settlement. The payment flow’s state-committing operation, executed under the selected scheme and network rather than merely inspecting authorization. [14]
x402 v2 /settle semantics. Stable ID: DN-TERM-020.
Keep the distinction: Verification is not settlement. Ordering depends on the resolved flow; some flows omit a separate verify step.
Ask before using the term: Does your evidence report validation, submitted execution or a completed settlement result?
11. Payment authorization / Payment capture
Payment authorization. For an eligible payment method, approval that places a hold on funds so an amount can be captured later within the permitted window. [15]
Stripe’s manual-capture payment documentation. Stable ID: DN-TERM-021.
Payment capture. The operation that captures an authorized amount, converting the eligible hold into a collected payment under the method’s rules. [15]
Stripe’s manual-capture payment documentation. Stable ID: DN-TERM-022.
Keep the distinction: A hold is not captured revenue, and capture is not the same as a later bank payout. Eligibility and expiration depend on the payment method and implementation.
Ask before using the term: Which amount is merely authorized, which is captured and which has reached the bank?
12. Idempotency key / Request ID
Idempotency key. A caller-supplied value that lets an API recognize retries of the same operation and apply its documented duplicate-request behavior. [16]
Stripe API idempotency; v1 and v2 semantics differ. Stable ID: DN-TERM-023.
Request ID. An identifier assigned to an individual API request for tracing it through the provider’s response and diagnostic records. [17]
Stripe Request-Id response header and request logs. Stable ID: DN-TERM-024.
Keep the distinction: A trace identifier does not prevent duplicate execution. An idempotency key’s retention, failure and retry behavior must be read in the relevant API version.
Ask before using the term: Are you correlating one request or controlling retries of one intended operation?
13. Event timestamp / Observed timestamp
Event timestamp. The time when an event occurred, as represented by the emitting system in the OpenTelemetry log record. [18]
OpenTelemetry Logs Data Model: Timestamp. Stable ID: DN-TERM-025.
Observed timestamp. The time when the collection system first observed an event, rather than the time assigned to the event by its source. [18]
OpenTelemetry Logs Data Model: ObservedTimestamp. Stable ID: DN-TERM-026.
Keep the distinction: Transport delay, batching and different clocks can separate these values. Their difference alone is not a causal explanation or a validated latency measurement.
Ask before using the term: Whose clock supplied the time, and which event did that clock measure?
14. Order acknowledgement / Trade fill
Order acknowledgement. An exchange response acknowledging an order request and its identifiers; the response mode may omit execution details. [19]
Binance Spot REST API ACK response mode. Stable ID: DN-TERM-027.
Trade fill. An executed part of an order, represented by trade details such as quantity and price; one order may have multiple fills. [19]
Binance Spot REST trade and fill fields. Stable ID: DN-TERM-028.
Keep the distinction: An order ID establishes a record to reconcile, not a completed position. Use execution evidence and quantities to distinguish no fill, partial fill and completed execution.
Ask before using the term: What quantity actually traded, and which execution record supports it?
15. Pending transaction / Finalized block
Pending transaction. A broadcast transaction waiting in a transaction pool for possible inclusion in a block. [20]
Ethereum transaction lifecycle. Stable ID: DN-TERM-029.
Finalized block. A block secured by Ethereum’s checkpoint-based consensus finality, whose reversal would violate the protocol’s economic-security assumptions. [21]
Ethereum proof-of-stake consensus. Stable ID: DN-TERM-030.
Keep the distinction: Broadcast, inclusion and finality are separate states. Finality concerns the chain’s accepted history; it does not establish that a business objective succeeded.
Ask before using the term: Are you recording a submitted transaction, its receipt or a finalized chain state?
16. Ethereum account nonce / Kraken API nonce
Ethereum account nonce. An account-state counter used in transaction or contract-creation sequencing; applied EIP-7702 authorizations can also increment the authorizing account’s nonce. [22]
Ethereum account state, including EIP-7702. Stable ID: DN-TERM-031.
Kraken API nonce. An increasing unsigned 64-bit value sent with each private REST request made under a particular Kraken API key. [23]
Kraken Spot REST authentication. Stable ID: DN-TERM-032.
Keep the distinction: These counters have different owners and acceptance rules. An Ethereum account counter is not an exchange API freshness value.
Ask before using the term: Which system owns the counter and defines its next accepted value?
17. Externally owned account (EOA) / Contract account
Externally owned account (EOA). An Ethereum account controlled by private-key authorization; current Ethereum also permits its code delegation through EIP-7702. [22]
Ethereum account control model. Stable ID: DN-TERM-033.
Contract account. An Ethereum account whose behavior is controlled by deployed contract code rather than its own private key. [22]
Ethereum account control model. Stable ID: DN-TERM-034.
Keep the distinction: Delegated code means “EOA” should not be shortened to “always has no code.”
Ask before using the term: Who can authorize activity, and what code can execute for this account?
18. Stablecoin / Tokenized deposit
Stablecoin. A cryptocurrency designed to track a specified reference asset, currency or basket, with the aim of limiting changes in its value against that reference. [24]
BIS conceptual glossary, 2023; no issuer-specific legal classification. Stable ID: DN-TERM-035.
Tokenized deposit. A bank deposit represented on a programmable platform, retaining the underlying claim against the issuing commercial bank. [24]
BIS conceptual glossary, 2023. Stable ID: DN-TERM-036.
Keep the distinction: A target value and a bank liability describe different attributes. The label alone establishes neither guaranteed redemption nor the protection available to a particular holder.
Ask before using the term: What is the legal claim, against which issuer, and on what redemption terms?
19. Know Your Customer (KYC) / Know Your Agent (KYA)
Know Your Customer (KYC). Here, shorthand for identifying a customer and verifying that identity through reliable independent evidence within a broader customer-due-diligence process. [25]
FATF Recommendation 10; local implementation determines duties. Stable ID: DN-TERM-037.
Know Your Agent (KYA). In Sumsub’s named framework, a process that links an AI agent to verified human identity to support accountability for automated activity. [26]
Sumsub’s January 2026 product announcement. Stable ID: DN-TERM-038.
Keep the distinction: These are not interchangeable certificates. KYC also sits within broader due diligence; this KYA definition is a provider’s stated approach, not a finding of universal regulatory recognition.
Ask before using the term: Which party is identified, which authority is evidenced and whose rules apply?
20. EMV payment token / ERC-20 token
EMV payment token. An alternative value replacing a card’s primary account number, with use restricted to an intended merchant, device or payment context. [27]
EMVCo Payment Tokenisation framework. Stable ID: DN-TERM-039.
ERC-20 token. A token implemented through the ERC-20 smart-contract interface for balances, transfers and spending allowances on Ethereum-compatible execution systems. [28]
ERC-20 interface as documented by Ethereum. Stable ID: DN-TERM-040.
Keep the distinction: A protected card credential and a programmable token share a word, not a common financial claim. The ERC-20 interface does not itself specify redemption or ownership rights.
Ask before using the term: Does “token” mean a payment credential, a ledger asset or a claim defined elsewhere?
Methodology, limitations and corrections
DN selected terms whose confusion can change a reader’s interpretation of authority, execution, evidence or financial rights. Definitions paraphrase primary sources and deliberately retain source scope. A protocol definition is tied to its documented version where available. An implementation-specific term is not promoted into a universal standard. Conceptual sources are identified by their original context rather than treated as current legal advice.
The forty stable IDs refer to this edition’s definitions. The paired record adds a source URL, an editorial review date, the actual UTC source-check date and a confusion boundary. The instrument selects one or both definitions and records whether the reader declares a matching scope. Unknown remains unknown; a declared match remains user-entered. The downloadable JSON contains the complete selected term records, not only the displayed summary.
This is a reference asset across DN’s existing decision instruments. It does not repeat their product rankings or calculate performance. If a protocol changes, update the affected definition through a documented new version while preserving the stable ID and historical edition. That maintenance process is a proposal for this reference, not a claim that every linked source will remain unchanged.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version 1.0.0, 2026-11-14. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Is there one official definition of an AI agent?
The term is used in several ways. This glossary explicitly attributes the agent/workflow distinction to Anthropic’s architecture taxonomy. For a real product, ask which choices the model makes, which paths are fixed and what permissions actually apply.
Why are the AP2 mandate names different from some earlier explainers?
This edition uses the v0.2 specification’s Checkout Mandate and Payment Mandate. Historical examples using earlier terminology should retain their own version context rather than being silently read as current v0.2 definitions.
Can a machine consume the selected definitions?
Yes. The local record tool exports JSON containing the selected stable term IDs, definitions, source URLs, scope and review dates, together with your entered context. The export does not claim that your implementation was inspected.
Does the glossary certify KYC, KYA or a token’s legal rights?
No. Customer-due-diligence duties depend on the applicable rules. KYA here describes a named provider framework. A token’s contractual rights and redemption terms require their own evidence; an interface or label does not establish them.
Why distinguish verification, settlement and outcome?
They answer different questions: whether a condition was checked, whether a payment state changed and whether the intended service or business result occurred. One record should not be used to claim all three without evidence.
Primary sources
- Anthropic — Building effective agents. The explicitly attributed architectural distinction between predefined workflows and LLM-directed agents; originally published in December 2024. Reviewed 2026-11-13.
- MCP specification, version 2026-07-28. MCP as a protocol for connecting AI applications with external capabilities and context; version scope retained. Reviewed 2026-11-13.
- A2A — Core Concepts. Remote-agent interaction, stateful tasks and task artifacts; reviewed documentation, not a claim that every response creates a task. Reviewed 2026-11-13.
- MCP 2026-07-28 — Tools. Server-exposed callable tools, distinct from resources. Reviewed 2026-11-13.
- MCP 2026-07-28 — Resources. URI-identified context data exposed by a server. Reviewed 2026-11-13.
- MCP 2026-07-28 — Prompts, official repository. Discoverable prompt templates containing structured messages and optional arguments. Reviewed 2026-11-13.
- Agent Skills — Overview. Portable skill folders containing SKILL.md and optional scripts, references or other resources. Reviewed 2026-11-13.
- OWASP — Authorization Cheat Sheet. Authentication verifies identity; authorization controls permission for an action or resource. Reviewed 2026-11-13.
- AP2 v0.2 — Specification. Current v0.2 Checkout Mandate and Payment Mandate roles; checkout authorization is distinct from payment authorization. Reviewed 2026-11-13.
- AP2 v0.2 — Payment Mandate. A mandate authorizing payment for a particular checkout and its verification roles. Reviewed 2026-11-13.
- UCP — Checkout capability. Checkout state, readiness, completion in progress and completed order distinctions. Reviewed 2026-11-13.
- UCP — Order capability. An order entity is a current-state snapshot with fulfillment and adjustment information. Reviewed 2026-11-13.
- IETF RFC 9110, section 15.5.3 — 402 Payment Required. HTTP 402 is reserved for future use in the base HTTP specification; it does not itself define payment execution. Reviewed 2026-11-13.
- x402 specification v2, official repository. PaymentPayload; read-only verification; state-committing settlement; scheme and payment-flow scope. Reviewed 2026-11-13.
- Stripe — Place a hold on a payment method. Eligible payment authorization holds and later capture, within payment-method and timing constraints. Reviewed 2026-11-13.
- Stripe API — Idempotent requests. Idempotency keys and the need to retain API-version-specific retry semantics. Reviewed 2026-11-13.
- Stripe API — Request IDs. Per-request diagnostic identifiers exposed through Request-Id and logs. Reviewed 2026-11-13.
- OpenTelemetry — Logs Data Model. Timestamp as event time and ObservedTimestamp as the time the collection system observed the event. Reviewed 2026-11-13.
- Binance Spot REST API — Trade. ACK, RESULT and FULL response modes; executed quantities and trade-fill details are distinct from order acknowledgement. Reviewed 2026-11-13.
- Ethereum — Transactions. Broadcast transactions enter a pending pool before inclusion in a block. Reviewed 2026-11-13.
- Ethereum — Proof-of-stake and finality. Checkpoint-based consensus finality and its economic-security assumptions. Reviewed 2026-11-13.
- Ethereum — Accounts. EOA and contract-account control; account nonce; EIP-7702 code delegation and nonce effects. Reviewed 2026-11-13.
- Kraken — Spot REST Authentication. An increasing unsigned 64-bit nonce for each private REST request using a particular API key. Reviewed 2026-11-13.
- BIS — Blueprint for the future monetary system, glossary. Conceptual definitions of stablecoin and tokenized deposit; the latter is a claim on a commercial bank. Reviewed 2026-11-13.
- FATF Recommendations — Recommendation 10. Customer identification and verification using reliable independent sources as part of broader customer due diligence; opened edition updated October 2025. Reviewed 2026-11-13.
- Sumsub — AI Agent Verification announcement. The named vendor’s KYA framework and agent-to-verified-human binding; not a universal legal standard. Reviewed 2026-11-13.
- EMVCo — EMV Payment Tokenisation. An alternative value replacing a card PAN, with restrictions on where or how the token may be used. Reviewed 2026-11-13.
- Ethereum — ERC-20 Token Standard. The smart-contract token interface, including balances, transfer and allowance functions. Reviewed 2026-11-13.
Turn the finding into a decision
Use this reference when writing an integration requirement, comparing a supplier’s claim or preparing a research brief. Start with the exact term and version, then ask for the evidence your decision needs. DN’s financial-agent architecture framework connects several of these distinctions to implementation decisions, while the outcome-receipt guide helps separate work, retries and payments.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
