Shards
Each shard owns a subset of entities and their state. When an entity on a shard is activated, that shard processes it independently of other shards. Shards are not separate chains with their own consensus. They are partitions within every replica. The network adds capacity by adding shards; entity placement is automatic.Clusters
A cluster is a full replica of the system: every shard, every entity. All execution happens inside a cluster. Replication and agreement happen across clusters.Why it matters for developers
When Alice pays Bob and Carol pays Dave, both activations execute concurrently if the entities land on different shards. Neither waits for the other. This is a direct consequence of partitioning state: independent work does not serialize.Cross-shard activations
When a component sends an activation to an entity on a different shard, that message becomes a continuation delivered to the target shard’s execution layer. Short cross-shard hops typically finalize within the same block; longer chains may carry across into the next block. A multi-hop workflow does not pay one block of latency per hop; most chains complete in a single block or two, regardless of how many shards they touch.What you don’t have to do
- You do not pick which shard your component lives on.
- You do not change your code based on shard topology. The topology is invisible to component logic.
- You do not write cross-shard transactions explicitly. Sending an activation to a component on another entity uses the same code regardless of placement.
What you do have to know
- Operations across entities are asynchronous (delivered as activations), not synchronous.
- There is no atomicity guarantee across entities. See Activations and Components for design patterns.
Related
- Entities and accounts: what gets partitioned across shards.
- Components: the unit that lives on a shard.
- Activations: how cross-entity work is submitted.
- Finality: where cross-shard continuations finalize.