]> libp2p

manu@libp2p.io

Action State Group, Inc.

steven@actionstate.ai

Network Working Group NFC agents evidence libp2p measurement When an AI agent finds a counterparty, interacts with it, and pays it, the interaction crosses every layer of the stack: a physical tap between two devices, the hardware that holds their keys, a transport session, peer discovery and gossip, and finally an application record of what was agreed, paid, and delivered. Each layer produces its own evidence, and today nothing joins them. This document puts the near-field tap at the center and follows one progression, from tap to rendezvous, authenticated session, interaction, payment, and evidence record. For each layer it states what evidence the layer can contribute, what a verifier has to trust, and how a single verifiable record can cite all of it by digest. It treats hardware attestation and a transparency log checked by independent witnesses as complementary roots of evidence that answer different questions, describes how light nodes can check one interaction through evidence requests instead of replicating a swarm, and asks which measurable observations can independently corroborate such a record. It is a problem statement and research agenda for discussion in MAPRG, not a protocol specification.

Introduction Agents are starting to meet and transact in person as well as online. Two people's agents find each other across a table and exchange a credential; a delivery robot hands a parcel to a building's concierge agent; a phone agent pays a vending agent. The natural first step in each case is a near-field tap. The tap is short-range, needs physical presence, and can carry a key. The first thing a tap does is let two agents find each other. After the tap the interaction moves up the stack along one progression:

From tap to evidence record rendezvous -> authenticated session -> interaction -> payment -> evidence record ]]>

The two devices use what the tap carried to open an encrypted transport session to each other, possibly find other peers through a distributed hash table, share state over gossip, interact, and, in some cases, pay and deliver. Afterwards someone who was not present, such as an auditor, a dispute handler, or the payer's own employer, may need to check what happened. Evidence exists at every one of those layers. A secure element can sign what it read. A processor can trace what it executed. A transport handshake binds a session to a key. A DHT record and a gossip message can be signed. An application can seal a record of the agreement. What is missing is the connection: a checker today gets either every layer's raw logs or nothing, and has no way to know that the key in the tap is the key in the session is the key that signed the payment record. This document argues that the tap is the right anchor to build that connection from, because it is the one moment where both parties are physically present. Discovery is the general case and the one this document leads with; payment is the second scenario, and the one that shows most clearly why knowing that a tap occurred is not enough. The contribution is the layered evidence model, not an NFC payment protocol. through walk the stack. covers checkers who cannot hold everything. gives two end-to-end cases. asks what can be measured, which is the reason this belongs in MAPRG. This document marks each component as implemented, prototype, or future work. The core of this revision is the tap, the tap record, secure-element evidence, the move from the tap to an authenticated transport session, the record and bundle that cite them, and how these layers relate. Processor tracing, richer attestation, witnessed logs beyond the basics, gossip, and most of the light-node work are future work and are described only so the model shows where they fit.

Terminology

Tap:

A near-field exchange between two devices in physical proximity, carrying at least one public key and one nonce.

Record:

A signed, digest-committed statement by one party about an action it took or observed, such as an Agent Action Capsule .

Tap record:

A record of a tap, made by one of the two parties to it. It is an ordinary record with a tap-specific field ().

Citation:

A typed digest reference from a record to an artifact produced at another layer: the artifact's type, a digest algorithm, and the digest.

Checker:

Any party that verifies an interaction after the fact without having been part of it.

Light node:

A checker or peer that verifies specific records on request rather than holding a full copy of a swarm's state.

The Tap

What a Tap Can Carry A tap is small, so what it carries has to be chosen. The useful minimum:

• the initiating device's transport public key, which becomes its identity in the session that follows ();
• a fresh nonce from each side, so that a record of the tap cannot be replayed into a different interaction;
• optionally an endpoint hint for reaching the device off the near-field link;
• optionally a monotonic counter, where the hardware keeps one; and
• optionally a signature from the device's secure element over the above, for example as an NFC Forum Signature record .

For payments, the tap may additionally carry the payment terms, or start a contactless payment whose cryptogram is itself evidence produced by hardware.

What a Tap Establishes, and What It Does Not A recorded tap establishes that a device holding a given key took part in a near-field exchange that included a given nonce. With a secure-element signature, it also establishes which hardware produced that statement, to the extent the signing key's provenance is known. It does not establish distance. A relay attack can stretch a near-field exchange across any distance unless the protocol bounds round-trip time. It does not establish who the person is, or that the key holder was authorized to act for anyone. It does not by itself establish trust in the peer. Each record that cites a tap has to say which of these it relies on.

The Tap as Discovery and Rendezvous For two agents in the same place, a tap replaces a lookup. Instead of asking a DHT for a peer, the device already has the peer's key and can dial it directly. This removes one source of manipulation (a poisoned lookup) and one privacy leak (announcing interest in a peer to the swarm), at the cost of requiring presence. The tap exchanges the minimum needed to set up a rendezvous; everything stronger happens in the authenticated session that follows.

Recording the Tap A tap record is an ordinary record with a tap-specific field. No new record type is needed. Each side seals its own tap record: its own key, the peer's key, both nonces, and the time by its own clock. Neither signs the other's record. A checker that holds both records can confirm they name the same keys and nonces; a checker that holds one has one party's account. This is the same two-sided pattern used for settlement in . The tap-specific field separates two kinds of content:

Intrinsic to the tap:

what the near-field exchange itself carried: the keys, both nonces, the counter where there is one, and the secure-element signature where there is one.

Corroborated later:

what another layer establishes afterwards and the record cites by digest: that the authenticated session was bound to the tapped key (), a hardware attestation (), or an execution trace ().

Keeping these apart is what makes the security analysis in tractable. Replay, relay, and substitution attacks act on different parts: a replay reuses intrinsic content in a new interaction, a relay stretches the intrinsic exchange across distance, and a substitution swaps the corroborating artifact. A checker can see which part a given claim rests on.

Below the Tap: Hardware

Platform and Secure-Element Attestation A trusted execution environment, a TPM, or a secure element can sign a statement about its own state, in the RATS sense , for example as an Entity Attestation Token . A record cites such a statement by digest, and a checker verifies it with the issuer's own verifier. The runtime extension for Agent Action Capsules already defines this citation (attestation_refs), and a verifier there never reports a grade higher than the foreign verifier's result. Secure-element evidence for the tap is in scope for this revision; richer platform attestation is future work.

Processor-Level Tracing (Future Work) Processor trace facilities can record the control flow a core actually executed. As evidence, a trace answers "what code ran" more directly than any software log, but traces are large, and tying a trace to one interaction needs the same nonce discipline as the tap. A record can cite a trace, or a digest of a trace summary, without carrying it.

Complementary Roots of Evidence: Hardware Attestation and a Witnessed Log Hardware attestation and a witnessed transparency log are complementary roots of evidence that answer different questions. They are not interchangeable roots of trust. Hardware attestation answers what ran, under keys whose provenance runs back to a manufacturer. Not every device has such hardware, and not every checker trusts the manufacturer. A witnessed log answers a different question. Each record is appended to a log whose checkpoints are cosigned by independent witnesses, or registered with more than one transparency service . That does not say what ran. It says that a record existed by a certain time and has not changed since, and it depends on no single operator. The two compose. A record can cite a hardware statement and also be covered by a witnessed log; the first speaks to the device, the second to the record's history. A checker should report each claim against the root that supports it and should not present one as a substitute for the other.

Above the Tap: Network

From Tap to Authenticated Session: Transports Dialed by Key With a transport that dials peers by public key, such as libp2p or Iroh over QUIC , the key exchanged in the tap is the address and the session's authenticated identity. The handshake then binds the session to the same key the tap carried. A record that names its counterparty by that key is naming the peer it physically tapped, if the tap record is available. This step is in scope for this revision.

Discovery Beyond the Tap: DHTs in Private Swarms Beyond the tapped peer, agents find others through a Kademlia-style DHT , often within a private swarm. A signed provider record says what a peer advertised, not what it later did. Lookups are a privacy cost (they reveal interest) and an integrity risk (a poisoned routing table returns attacker-chosen peers). The tap avoids both for local peers; the DHT remains for everyone else.

Dissemination: Gossip and Pub/Sub (Future Work) Gossip protocols such as gossipsub spread state through a swarm. Signed messages give per-message authenticity, but full gossip means every node receives every message, which is the resource cost light nodes () are meant to avoid. Gossip is also where operational telemetry about the network itself can be published in a verifiable form, the subject of .

The Evidence Layer: One Record That Cites Every Layer At the top, each party seals a record of the action itself: what was agreed, paid, or delivered . Each party appends its records to its own checkpointed log , so that removing or rewriting one later is detectable. The record cites the lower layers by digest. The last column marks what is in scope for this revision. Layers, artifacts, citations, and scope

Layer	Artifact	Cited as	Scope
Tap	each side's tap record	typed digest reference to the record	core
Secure element	signed NFC record or attestation token	attestation_refs entry	core
Transport	peer's public key	counterparty key in the record	core
Log	checkpoint and inclusion proof	carried in an evidence bundle	core
Discovery	provider record, when the peer was not tapped	typed digest reference	future
Gossip	message identifier	typed digest reference	future
Processor	trace or trace summary	typed digest reference	future

An evidence bundle packages a record with the artifacts it cites that the holder chooses to disclose, plus the proofs a checker needs, so the whole chain can be checked offline.

Light Nodes: Checking One Interaction Without the Swarm A checker rarely needs the whole swarm. It needs one interaction. Rather than downloading every message, a light node asks for evidence about the specific records it cares about, using the request model of : a request names the records, the holder answers with a bundle, refuses, or reports that the records do not exist, and each of those outcomes is itself recorded. The minimum a light node needs to check one record is the record, its inclusion proof, the checkpoint that covers it, and either a witness cosignature on that checkpoint or a transparency service receipt . That is small and fixed in size, whatever the size of the swarm. Partial messages in the gossip layer and evidence requests at the record layer are two forms of the same idea. A partial verifier establishes a bounded claim about one interaction. It never establishes the global state of the swarm, and its result must not be presented as if it had.

Worked Examples

Discovery: Two Agents Meet Two people's agents tap phones. The tap carries each device's transport key and a nonce from each side. Each phone dials the other by key over an authenticated QUIC session, and the session handshake binds the session to the tapped key. The agents exchange a credential over that session. Each side seals its own tap record and a record of the exchange that cites the tap record by digest, and appends both to its own log. A checker who later holds both sides' records can confirm that the key in the tap is the key in the session is the key that signed the exchange record. It cannot confirm, from these records alone, that the two devices were near each other unless the tap bounded round-trip time.

Payment: Tap to Pay Between Two Agents A phone agent taps a vending agent. The tap carries the vending agent's key, both nonces, and the price terms. The phone dials the vending agent over a key-addressed QUIC session; the phone pays (for example x402 on a testnet, as in ); the vending agent delivers. Each side seals its own records of the tap, the terms, the payment it observed, and the delivery, and appends them to its log. A light node later requests the payee's records and checks them offline. Payment shows why knowing that a tap occurred is not enough: a checker has to connect the payment to the identities, the transport session, and the record of what was delivered, and the citations in are what make that connection checkable.

What Exists Today The payment rail has run end to end in a reference implementation (implemented). The tap record, the secure-element signature, and the binding of the session to the tapped key have not yet run together (prototype at best). The processor trace has not been built (future). Both devices in any run the authors show will be operated by the authors, so the examples demonstrate separate devices, not separate parties.

Measurement Questions The central question for MAPRG is which measurable observations can independently corroborate a record made at the tap or the application layer, and what limits those observations have. A record is one party's statement. A network observation made by someone else can support it, contradict it, or say nothing about it. The questions below are organized around that.

1. Session corroboration: can transport-level observations (handshakes, connection events, peer identifiers) confirm that an authenticated session to the tapped key took place when a record says it did?
2. Tap-to-session latency: how long from the tap to an authenticated transport session, with and without a secure-element signature?
3. Evidence size per layer: bytes added by each citation, and by the bundle a light node receives for one interaction.
4. Light node versus full replication: bandwidth and time to check one interaction through an evidence request, against receiving the same state by gossip.
5. Tap discovery versus DHT discovery: success rate, latency, and lookup leakage for local peers.
6. Relay exposure: how often a tap without round-trip bounding can be relayed in realistic settings, and what bounding costs.
7. Witness coverage: how many independent witnesses a checkpoint gets in practice, and how quickly.
8. Trace cost (future work): overhead of processor tracing for an agent workload, and the size of a trace summary that is still useful as evidence.

Which of these existing libp2p telemetry can already collect, using the framework in , and with what limitations, is an open item for the next revision. None of the questions above is answered by this document.

Security Considerations The main threats follow the layers. Near-field relay attacks defeat proximity unless round-trip time is bounded. A replayed tap reuses intrinsic tap content in a new interaction; fresh nonces from both sides and, where available, a counter limit this. A substitution swaps a corroborating artifact; citing it by digest makes the swap detectable but does not make the artifact true. A compromised secure element signs whatever it is told. A poisoned DHT returns the wrong peer. A party can withhold records; the evidence-request model makes a refusal visible but cannot force disclosure. Throughout, a citation only says that a record named an artifact. A checker has to verify the artifact itself, with that layer's own verifier, before relying on it, and must not report a stronger result than that verifier gave.

Privacy Considerations A tap can expose a stable hardware identifier; devices should use per-interaction keys and randomized identifiers. DHT lookups reveal interest. Gossip metadata reveals who talks to whom. Processor traces can contain secrets. Records should carry digests of these artifacts, never the artifacts, and bundles should disclose only what a given checker needs.

Implementation Status This section records the status of known implementations at the time of posting, per , and is to be removed before publication. The evidence layer has reference implementations, and the settlement records have run end to end on two payment rails. No implementation of the tap record, the secure-element citation, or the processor-trace citation described here is known to the authors.

IANA Considerations This document has no IANA actions.

Informative References libp2p Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress number 0 IPTPS 2002, LNCS 2429 IRTF MAPRG, IETF 126 NFC Forum

Acknowledgments The authors thank Johanna Moran (libp2p) for her contributions to the ideas in this document, in particular the work on verifiable telemetry and measurement for libp2p deployments on which builds.