What is a Calimero Context?

Understanding isolated execution environments

Before diving into how data stays consistent across peers, it's important to understand another foundational concept in Calimero: the context.

Calimero is not a single global network where all data lives in the same place. Instead, it is built around the idea of isolated execution environments, where applications run in clearly defined, private spaces. These spaces are called contexts.

At a high level, a context answers a fundamental question:

• Who is allowed to participate, and where does the application state live?

---

Imagine a building, not a Blockchain

Think of the Calimero network as a large building. Inside this building, there are many rooms. Each room has its own people, its own conversations, and its own shared whiteboard. What's written in one room can't be seen or changed from another. In Calimero, these rooms are called contexts. A context is an isolated instance of an application, running with:

• • its own state
• • its own members
• • its own access rules

Even if two contexts run the exact same application, they behave as completely separate worlds.

A concrete example: Imagine your favorite chat application running on Calimero. The application itself is the chat app, but every direct message and every group chat is its own context.

A one-to-one DM is a private context shared only between two nodes. A group chat is a separate context with its own members, state, and permissions. Messages shared in a group never leak into a DM, and data from one group is completely isolated from another — even though they all run the same application on the same nodes.

Creating a context: opening a room

Let's say Alice deploys a Calimero application — perhaps a shared task board for her team. When the application is installed, a new context can be created. Behind the scenes:

• • The application's WASM code is installed
• • The initial state is set up
• • A unique context ID is generated
• • Alice becomes the first member and the owner of the context

This context now exists as its own execution environment. Nothing outside of it can see or affect its state. We can imagine a context at this point as a new room that has appeared in the building: only the people inside the room can see and interact with the whiteboard, and anyone new must be invited in by the owner or by someone with permission to invite others.

Invitations: deciding who gets in

Contexts in Calimero are invite-only by design. If Alice wants Bob to collaborate, she doesn't just share a URL. She sends an invitation tied to Bob's cryptographic identity. That invitation says:

• • Which context this is
• • Who is allowed to join
• • What permissions they'll have
• • Optionally, how long the invitation is valid
• • An invitation can also be open, allowing any identity to claim it

This is where access control begins. There's no global user list, no centralized permission service. Membership is enforced directly by cryptography and context rules.

Joining a context: stepping inside

When Bob accepts the invitation, something important happens. He doesn't just “connect” — he joins the context. At that moment:

• • The invitation is verified
• • Bob is added to the context's member list
• • He receives the current snapshot of the shared state
• • His node starts participating in synchronization

From now on, Bob is inside the room. Any updates Alice makes, Bob can see. Any updates Bob makes, Alice can see — assuming he has permission to do so.

How members stay in sync

Once inside a context, members need to stay up to date with each other. Calimero uses libp2p's gossip-based pub/sub for this. Think of it like this:

• • Every context has its own “conversation channel”
• • Updates are gossiped only to members of that context
• • Nodes outside the context never hear those messages

This means:

• • No global broadcasts
• • No accidental data leaks
• • No cross-context interference
• • Each context is noisy only to the people inside it.

What's being exchanged over these channels are CRDT-backed state updates. These updates allow peers to make changes independently, even while offline, and later reconcile their state safely once they reconnect. The gossip layer handles delivery, while CRDTs handle correctness and convergence.

CRDTs are a core part of how Calimero guarantees consistency in a peer-to-peer environment, but their internal mechanics deserve a deeper explanation. We'll cover them in detail in a dedicated blog post. If you're curious in the meantime, you can explore how CRDTs work in Calimero by checking the documentation.

Permissions: not everyone can move the furniture

Not all members are equal — and that's intentional. A context can have:

• • Admins, who can manage membership and permissions, and can be nominated or renounced through context governance
• • Members, who can read and mutate state
• • Read-only participants, who can observe but not change anything

Permissions define what actions a member is allowed to perform. Even if someone receives state updates, they can't mutate data unless the context allows it. This access control list (ACL) is part of the context itself — not bolted on later.

Isolation: walls that actually hold

One of the most important properties of a context is isolation. Context A cannot:

• • Read Context B's state withouth explicit permission
• • Subscribe to its updates
• • Call its methods

Note: Contexts are isolated by design, but with explicit permissions they can interact with each other using cross-context calls.

Even though both contexts may live on the same node, they behave as if they are on entirely different networks. Inside each context, there are two kinds of storage:

• • Shared storage, backed by CRDTs and synchronized across members
  • • Collaborative application data lives here and is visible to all authorized participants
• • Private storage, which never leaves the local node
  • • Secrets, caches, and other node-local or personal data are examples of private storage

The boundary between shared and private storage is strict.

Contexts and Blockchains: choosing your anchor

Some contexts live entirely off-chain. Others are tied to a specific blockchain ecosystem.

A context can be associated with:

• • NEAR identities
• • Ethereum addresses
• • ICP principals
• • Starknet accounts

This association allows the context to:

• • Verify identities using on-chain cryptography
• • Make verifiable claims about Blockchain state
• • Bridge on-chain and off-chain logic cleanly

Importantly, this association is per context, not global. Two contexts can use different chains — or none at all — while running on the same node.

Leaving a context: walking out without burning the room

Eventually, Bob might leave the team.

When his access is revoked:

• • He stops receiving updates
• • He can no longer call methods
• • The context continues to exist unchanged

The room remains. The whiteboard stays intact. Only the membership changes. Contexts have continuity independent of individual nodes.

Why contexts matter

Without contexts, everything would blur together:

• • Data would leak
• • Permissions would be global
• • Collaboration would be unsafe

Contexts give Calimero structure.

They allow:

• • Multiple teams to run the same app independently
• • One node to participate in many isolated applications
• • Strong access control without central servers
• • Clean, scalable collaboration

If CRDTs solve how data merges, contexts define where that data belongs.

---

Closing thoughts

A Calimero context is more than a namespace. It's a boundary, a membership list, a synchronization domain, and an execution environment — all in one.

It's a room in a peer-to-peer world where:

• • Only invited people can enter
• • Everyone sees the same shared reality
• • And nothing leaks through the walls

You can learn more by visiting the documentation, exploring the open-source repositories, or contributing directly. We actively encourage community feedback, feature requests, and contributions. If you have questions, you can always reach out via Discord or email (support@calimero.network). Calimero is built to be open, private, and owned by the people who use it.