A +1+1 is the smallest piece of infrastructure that can make an autonomous agent legible to the systems it operates in.
Three properties, bound together at the network layer. Each one enforced by infrastructure outside the agent. No amount of prompt injection, jailbreak, or compromised orchestration code can rewrite them.
What follows has three layers. Read the surface or dig in by choice.
Identity
An agent is a specific instance on specific hardware, controlled by a specific party, doing specific things on someone's behalf. A +1+1's identity layer pins all of that down so the agent can prove who and what it is to anything it talks to.
Every +1+1 binds three cryptographic facts together: a phone number (MSISDN) registered on a real cellular network, an NFT on a blockchain ledger that records ownership and metadata, and an attestation from the hardware substrate the agent runs on (TPM, secure enclave, or hardware root of trust). The binding is enforced by the issuance protocol. None of the three can be changed without invalidating the others.
A receiver of an agent's call, API request, or message can verify any or all of these facts. A telecom-level system gets the MSISDN automatically. A web-level system can query the ledger to confirm the number belongs to a registered agent rather than a spoofed human or a hijacked credential. A high-trust system can require the live attestation to confirm the agent's hardware state hasn't been tampered with since issuance.
The identity primitive is covered by parent claims 1 and 9 of US 12,574,738 B2: the two-NFT architecture where an identity token authenticates the subject against the SM-DP+ platform, and a second NFT carries the eSIM profile that gets unpacked onto the device's eSIM chip and bound to the MSISDN. The continuation extends this with claim 12 (attestation via TPM, secure enclave, or hardware root of trust).
Attestation runs before authorization. The provisioning server checks that the agent's hardware fingerprint matches the expected state. This closes the gap between “an agent claims to be X” and “this specific compute substrate is in fact running X.” It is the property that distinguishes a +1+1 from a software identity provider. Those issue credentials that can be exfiltrated and reused. A +1+1 is bound to silicon.
For multi-tenant deployments (CIP claim 16), the identity layer supports organizational hierarchies. Agents issued by a deploying organization carry that organization's cryptographic signature, and cross-organizational access grants can be enforced with scope limitations even when an agent operates inside a partner's network.
Scope
“What the agent is allowed to do” is encoded into the +1+1 itself, not into a config file the agent reads. The network checks the scope every time the agent tries to attach. If the scope says only between 9am and 5pm Pacific, only inside the US, only spending up to a hundred dollars a day, only on commercial carriers, those rules are enforced by the radio, not by the agent.
A +1+1's scope object carries four kinds of constraints. Temporal: explicit validity windows, start and end times, allowed days and hours. Geographic: permitted regions, defined by GPS bounds, named zones, geofences, or country codes. Role and purpose: what the agent is authorized to do, like place outbound calls, receive SMS, complete verification, transact, navigate web. Radio policy: permitted cellular networks (PLMNs), access point names (APNs), quality-of-service classes, frequency bands.
On every network attach, the provisioning server retrieves the scope object from the blockchain and evaluates each constraint against the current context. If any constraint fails, network access is denied. The agent doesn't get a partial connection or a degraded mode. It gets no connection until the constraints are satisfied.
Scope can be modified in real time. If an agent is showing concerning behavior but not severely enough to warrant termination, the scope can be downgraded: reducing permitted purposes, tightening time windows, lowering spending caps, without disrupting the agent's identity.
The scope primitive is the centerpiece of the continuation. Claims 4 and 15 define the mission-scope object: temporal, geographic, role, and radio-policy parameters. The enforcement architecture treats network access as a continuously evaluated condition, not a one-time grant.
This is what “zero-trust at the SIM layer” means in practice. No device is trusted without continuous validation against its mission parameters, and the validation runs before any application-layer code executes. Compare this to software-level guardrails, which can only act after the agent has already attached to a network and is making outbound requests. By that point, a compromised agent has had every chance to exfiltrate data or take action.
Real-time downgrade transactions (CIP claim 19) modify the scope of an existing +1+1 without revoking it. A scope modification is a blockchain transaction signed by an authorized wallet (the issuing organization or its delegate), recorded immutably, and propagated to the provisioning server. The next network attach picks up the new scope. This supports graduated responses to suspected compromise: tighten the leash before deciding whether to cut it.
Lifecycle
+1+1s are not permanent. They're issued for a purpose, used during that purpose, and terminated when the purpose ends. Some live for months. Some live for ninety seconds. The lifecycle is part of the primitive, not an afterthought. Every +1+1 knows how it ends, and every termination leaves a permanent record.
What an audit trail looks like
- scrolling into view…
Four phases. Mint: the +1+1 is created on demand, atomically with the agent's attestation and (in some cases) with payment. The mint is a blockchain transaction that records the issuing organization, the agent's identity, the scope object, and the validity period. Operate: during its valid window and within its scope, the +1+1 is a working phone number on a real cellular network. Every network attach is checked against the scope. Modify (optional): authorized parties can update the scope, extend or shorten the validity, downgrade access, all without revoking the underlying identity. Burn: the +1+1 is cryptographically revoked, the eSIM profile is deleted from the device, the MSISDN is released, and revocation signals propagate to the mobile network operator and the SM-DP+ platform. Burn is irreversible.
Ephemeral +1+1s, minted for a single task and burned on completion, are first-class. They can be minted in seconds programmatically, used for a 90-second verification flow, and burned before the API response returns to the caller.
The lifecycle primitive is covered by CIP claim 8 (ephemeral connectivity with cryptographic burn and immutable audit), claim 7 (revocation transactions), and claim 19 (downgrade transactions).
The burn operation is multi-component: the NFT is marked burned on the ledger (immutable), the eSIM profile is deleted from the device's eSIM chip (verifiable), and the network association is severed at the MNO and SM-DP+ level (enforced). The combination means that even a captured device yields no usable network credentials. The cryptographic state required to attach is no longer reconstructible.
This is the property that defense and high-security commercial deployments care about most. A compromised software identity can be revoked at the IdP, but the credential in memory remains valid until its session expires. A burned +1+1 cannot be brought back up by a clever attacker on the captured substrate. The cryptographic state is gone.
For routine commercial use, burn is also the cleanest accountability primitive available. Every +1+1issued, used, modified, and burned generates a complete, ordered record. The record survives the agent, the issuing organization, and the device. When someone six months later asks “what was that agent allowed to do, what did it do, who terminated it, when,” the answer is a query against the chain.
How the three properties hold together.
The three properties are inseparable by design.
An identity without scope can do anything, and is not meaningfully constrained. A scope without lifecycle cannot be tightened or terminated, and is not meaningfully enforced. A lifecycle without identity cannot be attributed to a specific agent, and is not meaningfully accountable.
This is why a +1+1 is a single primitive, not three APIs stitched together. The combination is the architecture. The patent estate covers the combination.
Two further properties.
Identity, scope, and lifecycle are the three properties every +1+1 carries by default. Two more layer on top.
Reputation. A +1+1accumulates behavioral history that other systems can query. Agents with clean records earn trust. Agents with concerning patterns get downgraded automatically. The reputation graph (CIP claim 13) is the foundation for an agentic identity system that doesn't have to start over for every new interaction.
Accountability. Every +1+1can be bound to a wallet that pays for connectivity (CIP claim 17), making the agent's economic identity inseparable from its operational identity. Combined with the immutable audit trail, this closes the loop between behavior and consequence.
Where this becomes a spec.
Everything above is conceptual. The actual interfaces (SDK methods, RPC schemas, attestation flows, network adapter specs) are in active development with design partners.
If you want input into the spec, get on the list.