Emergent Constructs

As the universe evolves, new elements, kinds, and sets emerge, all governed by the foundational original laws established in the early stages of its development.

Discovery of New Elements

Elements are needed by objects, without them objects can not be constructed.

In order for elements to be used by objects, they must be registered in the Element Registry—this process is referred to as their element discovery.

Information elements do not require prior registration. They can be used directly as needed. Currently, there is no established method for registering materials. It is anticipated that, as the need arises, a method for registering and authorizing materials will be implemented.

Values

To register a value element in the registry.

function registerValue(TokenStandard std, address addr, bytes32 data)
    external
    returns (uint64);

Artifacts

To register a artifact element in the registry.

function registerArtifact(TokenStandard std, address addr, bytes32 data, uint64 idBeg, uint64 idEnd)
    external
    returns (uint64);

Emergence of New Kinds

Kinds serve as a type system for tokens, functioning as abstractions that allow real-world concepts to be represented within the crypto space. They simplify the process of creating interactive tokens, reducing complexity for developers. Essentially, kinds are like "species" within a universe, making the system more versatile.

To encourage reusability and prevent misuse, kinds are created with a cost. This approach incentivizes users to utilize existing kinds rather than continually creating new ones.

A fundamental aspect of the Previous chain's tokenomics is that kind owners are rewarded economically when their kinds are utilized. The system tracks which kinds are being employed by various objects, ensuring transparent and fair rewards for their owners.

To register a kind in the Kind Registry:

function register(ElementType[] memory shape, bytes32 code, bytes32 gene, uint64[] memory rels)
    external
    returns (uint64);

Formation of New Sets

By leveraging elements, kinds, relations, and transforms, the creation of sets has become significantly more streamlined. These abstractions distribute the workload traditionally managed by teams to individuals across the entire network, all on-chain.

This not only simplifies the creation process and facilitates efficient on-chain collaboration, but also lowers the overall investment required.

To prevent spam, the creation of new sets involves a cost.

To register a set in the Set Registry:

function register(address law, bytes32 lineage)
    external
    returns (uint64);

Development of Objects

The lifecycle of objects is managed by the set contract associated with the set object. Function calls are made to this contract to guide the object’s development.

Creation

Objects can be created from sets.

The method for creating new objects is determined by the set contract. A recommended function signature is:

function create(uint64 id, bytes memory data) external returns (uint64);

In this function:

The id can be 0, meaning no specific ID is required, or non-zero if a specific ID is desired.
The data parameter can be empty or contain additional information, which is interpreted by the set contract according to its requirements.

Update

Objects have the ability to change through a call to the update function:

function update(uint64 id, bytes memory data) external returns (Meta memory);

A set contract may choose not to implement the function, or it can revert the transaction, effectively disabling the ability to update the object.

Upgrade

Objects have the ability to evolve by applying updates from their kind or set objects. This process is initiated through a call to the upgrade function:

function upgrade(uint64 id, uint32 kindRev, uint32 setRev)
    external
    returns (Meta memory);

It's important to note that updates to kind or set objects do not automatically trigger an upgrade. The upgrade only occurs when initiated by the object's owner, ensuring that the control over the object remains with its owner.

For unminted objects, the set contract can determine whether to adopt the most recent version of the kind or set object or a specific vision, allowing flexibility in how upgrades are managed.

A set contract may choose not to implement the function, or it can revert the transaction, effectively disabling the ability to upgrade the object.

Everything Theory