Lifecycle
From creation to composition: the proposed life of a Sigil.
ProposedA Sigil moves through five stages, from construction by its creator to composition with other pieces.
- 01CreateConstruct and serialize a recordDraft
- 02PublishSubmit it to ElysiumOpen design
- 03IndexDiscover it from chain dataProposed
- 04ValidateApply version and standard rulesDraft
- 05Reference / ComposeLink it into assembliesOpen design
Implemented versus conceptual
Based on the current repository, none of these stages is implemented by Saelis software. What exists today is Elysium itself: any developer can already send transactions with arbitrary data to Elysium testnet and read them back with standard tooling. The Saelis-specific parts of each stage are specifications in progress.
| Stage | Exists today | Saelis-specific work |
|---|---|---|
| Create | Any client can build a JSON payload | Final envelope format |
| Publish | Elysium accepts transactions with arbitrary data | Choice of transport |
| Index | Elysium RPC exposes blocks, transactions and logs | Reference indexer |
| Validate | Nothing | Envelope and standard rules |
| Reference / Compose | Nothing | Reference and assembly rules |
Create
The creator constructs an envelope, fills in metadata and references, and adds a body conforming to the declared standard, if any. The envelope is serialized to bytes in the canonical encoding.
Creation happens entirely on the client. Nothing is onchain yet.
Publish
The creator signs and submits a transaction that carries the serialized envelope to Elysium. Once the transaction is included in a block, the Sigil has a creator, a position and, under the current proposal, an ID.
Publishing does not imply validity. A transaction can be included in a block and still contain an invalid envelope.
Index
Indexers observe new blocks, extract candidate records according to the transport and decode them. Indexers must also handle chain reorganizations, which are possible before a block is final. See Indexing & Verification.
Validate
Each candidate is validated in canonical order: first the envelope, then the rules of its standard. The outcome is recorded alongside the Sigil, for example valid, invalid envelope or rejected by standard, so that applications can explain why a record has no effect.
Reference / Compose
Valid Sigils become available as reference targets. Later Sigils that reference them are linked, and assemblies are reconstructed from those links. Composition is ongoing: an assembly can continue to grow for as long as new pieces reference it.
Immutability
Once published, a Sigil cannot be edited or deleted. Changes are expressed by publishing new Sigils, such as a new version that references the previous one, or a standard operation that changes derived state.