Introduction to Standards

The Saelis envelope says that a record is a Sigil. A standard says what a particular kind of Sigil means.

Standards are how Saelis stays general. The base protocol knows nothing about tokens, collections or documents. Each of those is described by a standard that defines the body format, the available operations and the rules for deriving state.

#What a standard defines

Every Saelis standard specifies:

1. An identifier. A short, lowercase name declared in the envelope's std field, such as elc-20.
2. A body schema. The fields the body must and may contain, with types and constraints.
3. Operations. The distinct actions a Sigil can represent under the standard, such as deploy or transfer.
4. State rules. How an ordered sequence of valid operations produces state, such as balances or memberships.
5. Validation rules. Exactly when an operation is rejected, and what a rejection means.

A standard may not change the envelope rules. A Sigil that fails envelope validation is never passed to a standard.

#How indexers apply standards

An indexer processes Sigils in canonical order. For each valid envelope, it checks the std field. If it implements that standard, it applies the standard's rules. If it does not, it records the Sigil as valid but uninterpreted.

This means that an indexer can support a subset of standards and still agree with other indexers on every standard they share.

#Registered standards

ELC-20 is the first proposed standard. Additional standards can be introduced without changing the base protocol or existing standards.

#Proposing a standard

The process for proposing standards has not been formalized. The intended shape is:

• A written specification covering the five areas above.
• Test vectors: sequences of Sigils with their expected resulting state.
• A reference implementation of the state rules, independent of any particular indexer.
• Public review before the identifier is considered reserved.

#Versioning standards

A standard evolves by publishing a new identifier, such as a hypothetical elc-20-v2, rather than changing the rules of an existing one. Changing rules retroactively would change the state derived from Sigils that were already published, which breaks verifiability.