Vendor and Standard Reality
CoAP is a genuine engineering achievement, and the comparison below is not a quality criticism of it. RFC 7252, published by the IETF Constrained RESTful Environments (CoRE) working group in 2014, took the REST architectural style and rebuilt it for hardware that cannot carry TCP, TLS, and HTTP/1.1. It runs over UDP with a four-byte fixed header, defines GET, POST, PUT, and DELETE methods against URI-addressed resources, and uses confirmable and non-confirmable message types to offer reliability where a constrained device can afford it and best-effort delivery where it cannot. The design is small enough to implement in a few kilobytes of code and flash.
The surrounding standards work is substantial. RFC 7641 adds the Observe option, letting a client register interest in a resource and receive notifications on change without the battery cost of polling. RFC 7959 defines block-wise transfer for payloads larger than a single datagram. RFC 7252 specifies DTLS as the security binding, and RFC 8613 (OSCORE) later added object-security so that CoAP messages can be protected end to end across intermediaries and proxies rather than only hop by hop. CoAP is the application-layer transport in OMA Lightweight M2M (LwM2M), it underpins the CoRE Resource Directory (RFC 9176) for constrained-network service discovery, and it appears across industrial, building-automation, and consumer IoT stacks. Implementations are mature: libcoap, Eclipse Californium, aiocoap, and the CoAP support in Contiki-NG and Zephyr are widely deployed.
What CoAP does well, it does deliberately. It brought a familiar, cacheable, resource-oriented interaction model to the most constrained end of the network without dragging along the weight of the web stack it descends from. The gap analyzed here is not a defect in that work. It is a description of which layer holds authority in a protocol that was, by design, kept small.
The Architectural Gap
CoAP treats a message as a transport unit and delegates governance to the layers around it. This is the same architectural choice HTTP makes, and it is defensible for the environments CoAP targets. But it means the rules do not ride in the payload.
Consider where each governance concern lives. Trust and confidentiality are handled by DTLS or, for object-security, by OSCORE; both establish that a message is authentic and unmodified, which is a distinct question from what governance regime produced the data or which consumer scopes are eligible to receive it. Access control in LwM2M is a server-side access-control object, a table the management server consults, and it sits beside the resource representation rather than inside it. Resource discovery through the CoRE Resource Directory is a registry lookup: a device registers its resources with a directory, and clients query that directory. The directory is an external authority each participant reaches, and it holds the registration record rather than a cryptographic statement about the lineage or policy history of the resources it lists.
The consequence is that a CoAP resource representation is semantically flat with respect to governance. A temperature reading served from a calibrated industrial sensor and one served from an uncalibrated development board are structurally alike once both are authorized to answer a GET on their URI. Facts such as "this value was produced under a named credentialing authority," "this value is bound to a data-residency scope," or "this value is scoped to this trust radius" are expressed in a CoAP deployment at other layers, or encoded in a CBOR payload by convention (SenML, defined in RFC 8428, standardizes the measurement encoding, and governance is left to the deployment). Those conventions are bilateral agreements between endpoints, and their interpretation is re-established at each proxy, cache, or store-and-forward intermediary rather than carried in the protocol itself.
CoAP's proxy and cache model sharpens the point. CoAP explicitly supports forward and reverse proxies and cacheable responses keyed by the Max-Age option. A cached representation is keyed on freshness rather than on the trust conditions under which it was originally produced, and a proxy forwarding a request evaluates it against its own configuration rather than against a policy the origin would have applied, since the policy lives outside the message. OSCORE protects the payload's integrity across such a proxy, which is real and valuable, and integrity is a different property from governance: knowing a message was not altered is a separate question from knowing what regime authored it and where it is admitted to go.
What the Memory-Native Protocol Provides
United States Patent Application 19/366,760 discloses a substrate in which the unit of protocol execution is not a packet but an agent: a cryptographically signed, memory-bearing object comprising a unique identifier, a payload, a memory field, a transport header, and a digital signature. The distinction from CoAP is precisely the one the gap above describes. The governance CoAP places in surrounding layers, the filing places inside the object that travels.
The memory field, as the specification describes it, is an append-only record carrying verifiable lineage, access logs, and policy references. The lineage is a hash-chained, node-signed history of the mutations and zones the object has passed through, so a receiving node can confirm the object's current state derives from a trusted origin. The policy references point to policy agents that encode who may mutate the object, what quorum must be satisfied, and which behaviors are permitted. The transport header encodes delivery constraints the specification names directly: time-to-live, trust radius, semantic class, and scope-limited delivery paths. The signature is computed over a canonical serialization of the identifier, payload, memory field, and transport header, and is re-verified at every node before execution or forwarding, with rejected objects discarded and logged.
This changes what a routing decision is. The specification's dynamic routing protocol (DRP) selects a next hop not by address or hop count but by trust scores derived from the object's access log, its policy references, and network health signals, and it enforces the transport header's trust radius and TTL as hard constraints. Where CoAP resolves a URI against a directory and forwards toward an address, the memory-native substrate evaluates whether a candidate node is eligible under rules the object carries, and excludes policy-incompatible or out-of-scope nodes from the routing graph entirely. The specification's example scores candidate nodes against a policy-defined trust threshold and disqualifies those that fall below it or that exceed the object's remaining TTL budget.
Two further layers named in the specification operate on state a CoAP message does not carry. The adaptive consensus protocol (ACP) evaluates mutation proposals an object carries in its memory field, forming an ad hoc quorum scoped by the object's own policy references rather than by a fixed validator set, and appending the outcome to the memory trace. The network health monitoring system (NHMS) emits signed health agents that carry congestion, latency-variance, and entropy signals through the same substrate, so nodes adapt routing and quorum thresholds from the network's lived experience without an external monitoring plane. In CoAP terms, the analog of observability and access control both move into the object and its trace, rather than living in a management server or a separate telemetry system.
Crucially for the environments CoAP serves, the specification describes a stateless deployment mode. When a node holds no persistent memory, it relies exclusively on the data embedded in the received agent for trust evaluation, quorum participation, and policy enforcement. The specification names IoT devices, ephemeral containers, and anonymized relays as exactly the class of participants this mode is for. Governance that rides in the object is the mechanism that lets a resource-constrained, intermittently connected node enforce policy without reaching a directory or a policy server it may not currently be able to contact.
Composition Pathway With CoAP
The memory-native approach composes with CoAP rather than displacing it, and the specification is explicit that the substrate operates above the transport layer and can be carried over legacy transports including TCP/IP, HTTP, WebSockets, WebRTC, mesh relay, and delay-tolerant networking without changing the object's internal structure or behavioral semantics. CoAP over UDP is a natural member of that set.
The minimum-viable integration serializes an agent, in the object structure the specification defines, into a CoAP payload and moves it with ordinary CoAP methods: POST to submit an object to a node, GET to retrieve one, with block-wise transfer (RFC 7959) handling objects that exceed a single datagram. No change to libcoap, Californium, or aiocoap is required, and OSCORE can protect the object end to end across proxies exactly as it protects any other CoAP payload. The receiving endpoint verifies the object's signature and evaluates its memory field and transport header at the application layer. The cost is payload overhead, since the memory field and transport header add bytes; the specification's stateless mode and the compactness of a canonical binary encoding keep that increment within reach of constrained devices, which is the same envelope CoAP itself was designed to fit.
A deeper integration surfaces selected transport-header fields, trust scope and TTL in particular, as CoAP options or as SenML fields on the representation, so that a CoAP proxy or an LwM2M gateway can inspect and enforce scope without parsing the full object. A gateway bridging a constrained CoAP segment to a wider network can then refuse to forward an object whose declared trust radius excludes the destination, giving the proxy layer a governance check evaluated from the object itself. This requires the gateway to adopt the object's vocabulary but no change to the CoAP protocol itself.
The deepest integration places agent-verifying logic inside a CoAP-speaking node or proxy: the node validates the object's signature at intake, evaluates policy references and trust scope before its normal resource handling runs, and appends a trace entry to the object's memory field before forwarding. In the specification's terms this is simply a node running the DRP, and optionally the ACP and NHMS, over objects that happen to arrive as CoAP payloads. LwM2M deployments compose particularly cleanly, because LwM2M already defines a management server, an object model, and an access-control object; layering the memory-native object over LwM2M's resources moves the access-control decision into the resource representation the server already exchanges, without disturbing the LwM2M object model devices depend on.
Enablement and Embodiment Scope
A skilled implementer can build the approach described here from the disclosure. The object is a signed, canonically serialized structure with five named fields; the memory field is an append-only, hash-chained, per-node-signed log of lineage, access records, and policy references; the transport header carries TTL, trust radius, semantic class, and scope-limited paths; and the routing, consensus, indexing, and health layers each act deterministically on those fields. Verification is standard public-key signature checking over a canonical serialization. Trust scoring, quorum evaluation, and entropy-triggered reindexing are described with worked examples in the specification, including concrete thresholds and disqualification rules.
The disclosure spans a range of embodiments. Nodes may run in stateless mode, relying only on object-resident data, or in memory-aware mode with a persistent trust graph; the stack may include any subset of the routing, indexing, consensus, and health layers depending on node capability; and deployments range from single constrained edge devices through federated cross-domain zones to delay-tolerant and interplanetary links. Transport bindings named include UDP-borne protocols in the CoAP family alongside TCP/IP, HTTP, WebSockets, WebRTC, and mesh relay. Policy references may be embedded directly as canonical identifiers or resolved by alias against a zone-local table. Consensus may be omitted entirely, run autonomously under local policy, or validate reindexing through scoped quorum. These variations are enumerated so that the approach reads as a broad, enabling, dated public disclosure tied to the filing rather than a single point design.
Disclosure Scope
The inventive subject matter discussed here, the memory-native protocol substrate in which an agent's memory field, transport header, and signature govern its own routing, mutation, and consensus, is disclosed in United States Patent Application 19/366,760. Statements in this article about what the substrate provides trace to that application's specification.
The description of CoAP, RFC 7252, and the related IETF standards (Observe, block-wise transfer, OSCORE, SenML, the CoRE Resource Directory), OMA LwM2M, and the named implementations is provided as external context to frame the comparison. Those standards and products are the work of the IETF, the Open Mobile Alliance, the Eclipse Foundation, and their respective contributors, are described here at the architecture level as they are publicly documented, and are not claimed as part of the filing. The comparison is scoped to a single structural axis, where governance authority sits relative to the message, and is not a claim about CoAP's fitness for the constrained-device role it was designed to serve.
