xl1-knowledge
XL1 Blockchain Knowledge
This skill covers the XL1 blockchain (XYO Layer One) — a data-focused Layer 1 designed for high-throughput data applications. XL1 extends the XYO protocol with blockchain primitives: blocks, transactions, fees, staking, and consensus.
When you need to look up exact type definitions, install the relevant @xyo-network/xl1-* package and read the TypeScript declarations at dist/neutral/index.d.ts. The XL1 Protocol Yellow Paper provides the full protocol specification.
Skill identity. This skill's version is exposed in this file's frontmatter under metadata.version. Whenever you present a plan, an acknowledgement, or a completion summary, state which skills informed it, formatted as <skill-name> v<version> — read the version from this file's frontmatter, never from an example. When multiple skills from this plugin are active, each may be listed.
Skill layers
This is Layer 4 of the XYO skill stack: xy-development (1) → xy-toolchain (2) → xyo-knowledge (3) → xl1-knowledge (4) → xl1-patterns (5) → xl1-dapp-kit (6) → xl1-testing (7) → xl1-scaffold (8) → xl1-build (9).
- Builds on: xyo-knowledge (3) — protocol primitives (payloads, bound witnesses, modules, accounts, wallets);
xy-toolchainandxy-developmentfrom ariestools-skills (1–2) — build tooling (@ariestools/toolchain, ESLint, TypeScript config, Vitest) and coding conventions (TypeScript, Git, testing, workflow) - Hands off to: xl1-patterns (5) — when building application features, including the Statement Graph (append-only signed relationship claims,
@xyo-network/xl1-statement-graph-*) and other application substrates that are not core chain; xl1-dapp-kit (6) — when adopting the portable headless application contracts (@xyo-network/dapp-kit*); xl1-testing (7) — when verifying chain interactions against a local chain or Sequence; xl1-scaffold (8) — when starting a new XL1 project
Payload schema and identity rules
Before defining payloads or choosing identity/commitment hashes, read Payload Schema Evolution and Identity. New schema names use strict ASCII segments without structural version suffixes; $version is validated metadata; root hashes are the application default. Preserve shipped protocol hash contracts and do not let an unauthenticated BoundWitness version select consensus or signature rules.