Below is a list of terms (and their analogies) Insolar uses to designate its key concepts.


Tick that opens up a new block and is an event that ends the current time slot and starts a new one. Every pulse carries a new entropy/seed. Pulses are numbered in a monotonously increasing sequence.


Time period between two consequent pulses. Different slots may have different time duration.


Shardchain that keeps records of a subset of objects (lifelines) contained by a cloud. The shardchain has nodes allocated to store related records.

Material Jet

Jet that has no dependencies on other jets and is meant to provide persistence and access to data.

Virtual Jet

Logical group of affined objects for nodes allocated to process requests related to these objects. For example, each lifeline is considered an individual virtual jet. Such jets rely on material ones to operate: e.g., material jets store data while virtual ones do various calculations and validations of that data.

Jet Drop

Block of a shardchain with adjoined blocks of relevant sidechains that keep records produced at a specific pulse. Alternatively: Set of records representing changes of lifelines (and their sidelines) in a jet, all happened within a slot.


Decentralized application (dApp) that governs access, consensus, mutability, and other capabilities for other dApps. Alternatively: Collection of objects and related policies (construction, referencing, logical consensus, etc.). Domain also chooses a cloud to provide storage and processing for objects. Domain itself is a descendant of an object.


Smart contract, dApp, application object, addressable element of application logic or data. Resides within a domain. Object is stored as a lifeline. The first record of a lifeline is a permanent identifier of the object. Objects can be of different types and their lifespan is virtually unlimited and usually controlled by or through the object itself or by the object’s domain.


Similar to a transaction record; Insolar has a variety of record types. Record contains information on request, response, state control, maintenance, etc. All records fall into two main categories depending on their usable lifetime—a period during which the record can be used under normal circumstances:

  • Permanent records are generated by an application and its business logic. The logic controls the record’s usable lifetime, e.g., legal documents must stay for a period of action limitation.

  • Dust records are associated with a permanent record and are generated either by application or system logic. The usable lifetime of such a record is limited by maintenance procedures and usually measured in days, e.g., logs or transaction control records. Dust can also be used to identify complex forms of fraud or infringements; such will be registered as permanent records and the original dust records will be archived or removed.


Linked sequence of records related to an entity (object, operation, etc.). Stored as a unidirectional linked list, from older to earlier records. Filament is identified by the reference to its head (the first/earliest record) and every filament’s record has an affinity field that refers to the head. Filament is a general term that denotes different sequences of records. For example:

  • object’s state changes (lifeline);

  • requests (received, pending, answered, validated);

  • listings (delta and full snapshots of child object’s listings).


Chain of records (filaments) for a single object with relevant sidelines that represent auxiliary information about the object. Alternatively: Lifeline is all history and virtually all future changes of an object or of a dust. Lifeline never forks and belongs to a single domain. The first record (head) of a lifeline is an activation record and a permanent identifier. The last record (tail) is the latest state. Lifeline contains:

  • main filament (object’s state);

  • additional filaments (states of requests);

  • indices, listings, etc., related to the object.

Presence of additional filaments does not mean a fork to the object’s state as they carry only additional information.


Sidechain (filament) for auxiliary information such as logs.


Auxiliary object or record; a log record stored within a sidechain.


Removable sideline for a dust record.


Blockchain network (group of nodes) under the same node membership policy. The nodes provide storage and processing methods (including storage consensus) supported by the cloud (e.g., a specific blockchain implementation). Nodes can have different roles within the cloud.


Server that serves hardware capacity to a cloud. Node also represents an authorization (e.g., by putting a stake) of a member to participate in a cloud. Node is both a unique account and a unique address within a cloud. Node is always associated with a single member and with one or more hosts. Node performs only one role within a cloud but a member can have multiple nodes.


Entity of a physical/transport network, e.g., a server. Each host can have multiple network addresses, can be in different networks, and use various transport protocols and encryption standards.


External entity (user) registered within a special domain.


Set of hosts sharing same security, reliability, and network performance profiles and able to directly exchange data under at least one transport protocol and at least one encryption standard supported by all hosts. In other words, all hosts within the same network are able to use P2P communications without violation of security and other policies.