Sigils

A Sigil is a structured, identifiable onchain data record interpreted according to the Saelis metaprotocol. It is the smallest unit Saelis recognizes and the piece from which every larger structure is built.

Each Sigil answers four questions: what it is, who created it, what it means, and what it relates to.

#Anatomy of a Sigil

A Sigil consists of an envelope and a body. The envelope is defined by Saelis and is the same for every Sigil. The body is defined by the standard the Sigil declares, if any.

{
  "p": "saelis",
  "v": 0,
  "std": null,
  "meta": {
    "name": "Fragment 01",
    "description": "A standalone piece with no standard."
  },
  "refs": [],
  "body": {}
}

The full field reference is in Data Structure.

#Identity

Every Sigil has an identifier that is unique and derivable from chain data alone, without consulting an indexer.

The current proposal derives the Sigil ID from the transaction that publishes it. If exactly one Sigil may be published per transaction, the ID is the transaction hash. If multiple Sigils per transaction are permitted, the ID would be a hash over the chain ID, the transaction hash and the Sigil's index within the transaction.

A Sigil also has a position: the block number, transaction index and, where applicable, intra-transaction index at which it was published. Position defines canonical order and is used to resolve conflicts, such as two ELC-20 deploys of the same ticker.

#Metadata

The optional meta object carries descriptive information: a name, a description and an optional content pointer. Metadata is informational. It never changes how a standard interprets the body, so two Sigils with identical bodies are equivalent under a standard regardless of their metadata.

#Ownership semantics

Saelis distinguishes three roles:

• Creator. The account that signed the publishing transaction. This is recorded by the chain and cannot be forged.
• Holder. The account a standard considers to control the Sigil or the state it represents. For an ELC-20 transfer, for example, the holder of the transferred balance changes.
• Author. Any attribution in metadata. This is a claim, not a verified fact.

#Relationships

A Sigil may reference other Sigils through its refs array. Each reference names a target Sigil ID and a relation type. References are directional and immutable: a Sigil declares its references when it is published and cannot change them afterwards.

References are how pieces become structures. See The Puzzle Model and Assemblies.

#Serialization

The draft envelope is UTF-8 encoded JSON, preceded by a fixed content marker so that indexers can recognize Sigils cheaply and reject everything else without parsing. Short field names keep records compact, since every byte published onchain has a cost.

The draft requires:

• Valid UTF-8 and valid JSON, with a single top-level object.
• No duplicate keys.
• Numeric quantities encoded as decimal strings, so that values beyond the safe integer range of JSON parsers are never rounded.

#Verification

Verification is performed by indexers and proceeds in two stages:

1. Envelope validation. The marker, encoding, protocol identifier, version and required fields are checked. An invalid envelope is not a Sigil.
2. Standard validation. If the Sigil declares a standard, the standard's rules are applied in canonical order. A Sigil can be a valid envelope and still be an invalid operation under its standard, for example a mint that exceeds the remaining supply.

Both stages must be deterministic. Given the same chain history, any conforming indexer must reach the same result.

#Onchain and offchain data

It is important to be precise about what is actually stored onchain.

Elysium uses an AnyTrust data availability committee, with full-data posting to HyperEVM as a fallback. Retrieving historical Sigil data therefore depends on Elysium's data availability guarantees and on archive nodes or indexers retaining history.

#Composability

Because every Sigil shares the same envelope, tools that understand the envelope can work with any Sigil: displaying it, resolving its references and validating its structure, even if they do not understand its standard. Standard-specific behavior is layered on top.

This is what makes Sigils composable. A piece published for one purpose can be referenced by structures its creator never anticipated, and an application can build on records it did not create.