Boundaries and Assumptions

Understanding what Layr8 does—and doesn’t—help you evaluate where it fits and set appropriate expectations. This page is for architects and technical leads evaluating Layr8 for production use.

What Layr8 Guarantees

Authenticated identity. Every message is packed with authenticated encryption (ECDH-1PU). The recipient’s node resolves the sender’s DID Document, and the sender’s identity is proven during decryption — only someone with the corresponding private key could have produced the message. You always know who you’re talking to.

Policy enforcement. The node evaluates every incoming message against your configured policies — per-DID allow/deny lists, grant checks, and verifiable credential validation — before delivery to your agent. Unauthorized requests are rejected at the node level, not in your application code.

Tamper-evident audit. Interactions are recorded in hash-linked audit chains. Both parties maintain their own chains, which can be reconciled to verify agreement on what occurred. Tampering is detectable.

Node-to-node encryption. Message contents are encrypted between nodes using ECDH-1PU authcrypt. End-to-end encryption to self-hosted agents is coming soon.

Standards-based interoperability. Layr8 implements W3C DIDs, W3C Verifiable Credentials, and DIF DIDComm. Your identities, credentials, and message formats are not proprietary.

What Layr8 Does Not Guarantee

Guaranteed delivery. Like any networked system, messages that are sent may not arrive — the recipient’s node could be unreachable, a network partition could occur, or a policy change could reject a message that would have been accepted moments earlier. Layr8 queues messages and retries delivery, but does not guarantee that every message will eventually be delivered. If your use case requires explicit confirmation that a message arrived, build acknowledgment into your protocol — the same way TCP builds acknowledgment on top of IP.

When a message fails, the sender and/or recipient’s node sends a DIDComm problem report back to the sending agent. Problem reports are asynchronous—similar in purpose to HTTP status codes, but decoupled from the original request. Your agent receives them as ordinary messages.

Category	Code prefix	When it’s sent
Trust	`e.p.trust.*`	Authentication or authorization failed—expired key, missing signature, invalid signature, or policy rejection
DID	`e.p.did.*`	Recipient DID is invalid, not found, or could not be resolved
Transfer	`e.p.xfer.*`	Message could not be delivered to the recipient’s agent (no handler, transport failure)
Internal	`e.p.me.*`	Recipient’s node encountered an internal error

Problem report codes follow the DIDComm convention: {sorter}.{scope}.{descriptor}, where e = error, w = warning, p = protocol scope, and m = message scope. Your agent can match on prefixes (e.g., handle all e.p.trust.* reports the same way) rather than exact codes. See Problem Reports for the complete reference.

Message ordering. Messages between agents are not guaranteed to arrive in send order. If your use case requires strict ordering, implement sequence numbers at the application level or use a channel that provides ordering guarantees.

Exactly-once semantics. Network failures can cause duplicate delivery attempts. Design your agents to handle idempotent operations or implement deduplication logic.

Recipient behavior. Layr8 delivers authorized messages to recipient agents. It does not guarantee what the receiving agent does with it. Business logic failures, processing errors, and application bugs are outside Layr8’s scope.

Assumptions Layr8 Makes

Secure key storage. The node generates and stores private keys encrypted at rest (AES-256-GCM). Keys are decrypted into a secure in-memory store at runtime — agents never touch private keys directly. If a node’s key storage is compromised, an attacker can impersonate the agents hosted on that node. Use of HSMs, secure enclaves, or other mechanisms to further protect private key material are possible. If you are considering a use case that might require this, contact the team to discuss your specific requirements.

DNS integrity for did:web. The did:web method resolves DIDs through standard web infrastructure. This means DNS and TLS are part of the trust chain. If you require resolution that doesn’t depend on DNS, consider did:peer for direct relationships or other DID methods as they become supported.

Policy authors understand grant semantics. Policies define who can do what. Misconfigured policies can allow unintended access or block legitimate requests. Test policies thoroughly before production deployment.

Network connectivity. Agents need connectivity to their node to send and receive messages. The node queues messages for agents that are temporarily disconnected, but extended offline operation is not currently supported.

A DIDComm Mediator is a standard routing component that accepts messages on behalf of agents that may be offline, disconnected, or behind firewalls — then delivers them when the agent reconnects. Think of it like an email server holding messages until you open your client. A commercial Mediator Agent is on the Layr8 roadmap and will support fully offline and intermittently connected use cases. See Platform Status for availability.

Where Layr8 Fits

Think of Layr8 like a database engine. Oracle provides storage, querying, transactions, and security—but your application decides what data to store and what queries to run. Oracle is infrastructure; your application is business logic.

Similarly, Layr8 provides identity, messaging, policy enforcement, and audit—but your agent decides what messages to send and how to respond. Layr8 is coordination infrastructure; your agent is business logic.

┌─────────────────────────────────────────────────────────┐
│  Your Agent (business logic)                            │
│  - Decides what to send                                 │
│  - Processes received messages                          │
│  - Implements your use case                             │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│  Layr8 Node (coordination infrastructure)               │
│  - Authenticates senders                                │
│  - Enforces policies                                    │
│  - Encrypts/decrypts messages                           │
│  - Maintains audit chains                               │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
              Foreign Nodes / Network

This separation means:

You own your business logic. Layr8 doesn’t dictate how you process messages or what you do with them.
Layr8 owns coordination guarantees. Authentication, authorization, encryption, and audit happen at the infrastructure layer, consistently.
Changes are isolated. You can update your agent without changing Layr8. Layr8 can add capabilities without changing your agent.

This is the core value proposition: coordination that survives change. Participants evolve independently without cascading failures. Schemas change. Endpoints move. Teams reorganize. The coordination layer absorbs this, rather than propagating it.

Evaluating Fit

Layr8 is a good fit when:

You coordinate with external parties who run their own infrastructure
You need cryptographic proof of who sent a message and whether they were authorized
You want authorization decisions made at the infrastructure layer, not scattered through application code
You need verifiable audit trails for compliance or dispute resolution

Layr8 may not be the right fit when:

All your integrations are internal to a single trust boundary
You need sub-millisecond latency for every message
Your primary need is high-throughput event streaming with no identity requirements
You’re not ready to manage DID-based identity (though this is simpler than it sounds)

Next Steps

Architecture — See how a Layr8 Node fits into your infrastructure
FAQ — Common questions about operations and failure modes
Reference — Technical details on DIDs, DIDComm, and policies