Skip to main content
A component is a unit of executable code plus local storage, installed inside an entity. One entity holds many components. Index 0 is reserved for the account component, the default handler for activations sent to the entity without a specific component target. Within a single entity, components interact synchronously over consistent state. Across entities, they interact asynchronously by submitting activations to each other. Code is immutable once deployed; logic cannot be patched in place.

​
Why components, not contracts at addresses

On Solidity/EVM, a contract lives at one address and holds all state for all users of that contract in a single storage namespace. When Alice pays Bob, both reads and writes hit the same contract address. On the Grid, a contract is an interface (e.g., a fungible-token interface) deployed as verified, immutable code. That code is instantiated as a component installed inside each entity that uses it. When Alice pays Bob, Alice’s token-component and Bob’s token-component execute their logic in parallel. Each reads and writes only its own storage, inside their respective entities. There is no shared global state and no address contention. Mental model:
  • Solidity: one contract address, shared storage namespace, every user is a parameter.
  • Grid: one verified codebase, instantiated as many components across many entities. The user is the entity, with their own component installation.

​
Practical consequences

Independent participants do not contend on shared state. Alice paying Bob does not block Carol paying Dave, even if all four are on the same shard. Adoption is “install a component into my entity” rather than “call a contract at address X”. When you want to hold a token, you install the token component into your entity. Each component owns its storage independently, so the system scales horizontally: adding more participants does not add contention to any single state machine.

​
Lifecycle

Install → a component’s code is registered, and a copy is installed into your entity. Execute → you submit activations to your entity; the target component (or the account component if no target is specified) runs the relevant handler. Remove → a component instance is uninstalled from an entity. The code itself is never removed from the chain; only the entity’s installation reference is cleared.

​
Example: token transfer

Alice’s entity has a token component installed. Bob’s entity also has the same token component installed (same immutable code, different instances). When Alice sends a token to Bob:
  1. Alice submits an activation targeting the token component in her entity.
  2. Alice’s component decrements her balance.
  3. Alice’s component submits an activation to Bob’s entity, targeting Bob’s token component.
  4. Bob’s component increments Bob’s balance.
  5. Both components run the same verified code. The protocol guarantees they behave consistently. No need for a separate consensus round between them.