Open format · Governed network
OpenPayload is a neutral transport for application-defined data. Payloads move off-chain; chain-published policies coordinate who may handle them, where they may go, and the boundaries every participant follows.
CONTENT IS APPLICATION-DEFINED
CONTROL IS PUBLICLY RESOLVABLE
01 / THE PROTOCOL
OpenPayload separates the thing being moved from the rules that shape its journey. Applications own their data model. The network supplies identity-aware transport and a shared control plane.
Applications encrypt events, binaries, commands, telemetry, and multipart packages before sending them through Relay and Cache services. Directory resolves identities, keys, services, and policies.
The chain records identity, service authority, and exact signed policy documents. Directory and delivery services interpret supported policies from finalized state and enforce their permissions.
02 / OPEN BY DESIGN
OpenPayload defines the transport boundary, not your product category. The public envelope carries encrypted application-defined content; the content remains yours to invent.
Move application-defined events without forcing every system into a platform-owned schema.
Break larger payloads into verifiable parts and route them through the same open transport surface.
Carry sensor readings, device state, logs, and live updates across intermittent edges.
Keep the network neutral so builders can define new envelopes without waiting for a central roadmap.
03 / ONE RESOLVED DECISION
The network resolves recipient routing from finalized state and carries that bounded decision through permitted delivery services. Application event actions run alongside routing and recheck current authority before execution.
Wrap any application payload in a signed, bounded envelope.
Resolve the applicable recipient policy using Persona precedence, rule priority, and rule order.
Carry one policy decision and its boundaries through the delivery attempt.
Let each permitted service apply the same scoped outcome.
04 / CHAIN-PUBLISHED POLICY
A policy can express several context-aware outcomes under one version. An addressed Persona takes precedence over DID routing. Within a policy, the highest-priority matching rule wins; rule order breaks a tie. The selected recipient routing decision stays bounded through delivery. Application policies add independent event-driven actions without overriding routing or retention.
The chain verifies who may publish a policy and preserves its exact bytes and integrity hash. Directory and executing services validate the policy format, interpret its rules, and check current permissions before acting.
Conceptual capability view. Encrypted payload contents remain off-chain. Routing metadata, policies, and action templates are public; application logic stays with your application.
APPLICATION ACTIONS
Connect transport events to your application workflow while encrypted message content stays opaque to the network.
An Application policy can react to Relay acceptance, local delivery, or durable Cache storage. It can send an encrypted control message to an authorized DID or call an authorized HTTPS endpoint.
Relay acceptance means processing can begin; it does not mean delivery has succeeded.
Application actions run independently of recipient routing. They cannot change the recipient’s route or retention limits. HTTPS actions recheck current policy and domain authority before execution.
Explore shared policies ↗DOMAIN CONTROL
A domain Persona connects a DNS name to its operator’s decentralized identifier (DID). Signed DNS evidence is verified by the chain against its DNS root trust anchors.
Registration, renewal, transfer, and recovery use fresh DNSSEC evidence. Domain control proves authority over a name at verification time; reputation and organizational trust remain separate.
Register a domain Persona ↗An active DNS Persona can authorize policy HTTPS Calls to its domain and descendants. An Application uses a domain bound to its control DID.
ALPHA SNAPSHOT · UPDATED OCTOBER 29, 2026
Policy document publication was deployed October 17, followed by strict OpenPayload identity validation and service updates on October 18. This snapshot reflects those verified releases; the public alpha remains experimental.
Directory discovery and authorized identity updates; live Relay delivery; policy-limited Cache storage; signed DID, Persona, and Application policy documents; DNSSEC domain control and direct HTTPS Calls. Network identity operations accept only did:openpayload: identifiers.
Send your first payload ↗Talaria Chat has a registered Application, a domain binding, a published CacheStored policy, and a deployed push receiver. End-to-end background push still needs verification after the receiving device’s identity update.
See the workflow and verification status →Research sensor fleets, structured exchanges, and event-driven workflows show how builders could compose the primitives. They are examples rather than scale guarantees or turnkey products.
Explore the concept briefs →Understand live delivery, stored fallback, processing, failures, and unknown outcomes before deciding to retry.
05 / GOVERNANCE LOOP
Finalized intent coordinates compatible services without publishing payload contents or handing control to a central operator.
Publish a new policy, authority, or network parameter.
Validators establish one canonical, authorized state.
Bind the selected version and boundaries to one delivery attempt.
Compatible services apply the same outcome at the data plane.
06 / COMMUNITY-OPERATED
OpenPayload distributes responsibility across services that can evolve independently while following the same public state.
Resolve identity, keys, services, and applicable scoped intent.
↗Select and carry the finalized outcome while moving live payloads.
↗Provide policy-limited transient custody when endpoints are unavailable.
↗Finalize shared state and attest verifiable participation.
↗See arbitrary field observations move under project identity and chain-published collection policy.
Read the architecture →CONCEPT BRIEF / 02See identity, scoped intent, multipart envelopes, and bounded services compose into one resolved delivery.
Read the architecture →Ready when you are.
Hello, open network.
DELIVERED · NOWMandolare LLC's messaging overlay demonstrates how a focused application can use OpenPayload identity, live relay delivery, and transient routing.
Follow a signed Cache event into an authorized HTTPS workflow while message content stays encrypted.
Read the architecture →07 / BUILD IN THE OPEN
Build applications, operate infrastructure, publish policy, and help shape an open network for data that does not fit inside someone else's box.