Rules

What you find here

RULES is the fourth protocol on the Ordinalswall, alongside PACT, KINSHIP, and LINEAGE. The first three declare what is. RULES declares what follows.

A rule is not a fact. It is a public statement about how the facts on the wall may be read together. Anyone can inscribe a rule. This page shows the first one, explains how rules are shaped, and invites others to write their own.

The first rule

Inscribed on Bitcoin mainnet on May 4, 2026.

Inscription: 3e72086f88d791f5122e1cb0bab0727761ec2462ef4badf93dcd60a93e89840fi0

Expression:

IF kinship(A,B) AND avatar(A) AND avatar(B) THEN related(A,B)

The rule is intentionally simple. Its purpose was not to make a strong claim. It was to plant the protocol — to put the first artefact of a fourth kind on the wall, parallel to PACT, KINSHIP, and LINEAGE. From this seed, more can grow.

What an inscription looks like

The first RULES envelope, exactly as it sits in the witness:

{
  "p": "rules",
  "v": 1,
  "type": "RULE",
  "rule_id": "kinship-implies-relation",
  "expression": "IF kinship(A,B) AND avatar(A) AND avatar(B) THEN related(A,B)",
  "applies_to_protocols": ["pact", "kinship"],
  "declared_by": "Wiard Vasen",
  "declared_at": "2026-05-04T...",
  "note": "An inscribed rule is a public statement about how the wall may be read..."
}

p marks the protocol — rules. v is the version. type is the kind of inscription within the protocol; here, RULE. rule_id is a stable handle the rule can be referenced by. expression is the rule itself in human-readable form. applies_to_protocols names which protocols the rule reads from. declared_by and declared_at place the rule in the world. note is room for context.

This is what is on chain. Permanent, addressable, public.

Towards machine-readable rules

The expression field is for human readers. For a reader program to evaluate a rule deterministically, a machine-readable form helps. One proposal — not yet inscribed — adds an ast field that mirrors the expression as a tree, plus a predicate_definitions field that resolves which protocol each predicate comes from.

The first rule, in this proposed v2 shape:

{
  "p": "rules",
  "v": 2,
  "type": "RULE",
  "rule_id": "kinship-implies-relation",
  "expression": "IF kinship(A,B) AND avatar(A) AND avatar(B) THEN related(A,B)",
  "ast": {
    "if": {
      "and": [
        {"predicate": "kinship", "args": ["A", "B"]},
        {"predicate": "avatar", "args": ["A"]},
        {"predicate": "avatar", "args": ["B"]}
      ]
    },
    "then": {"predicate": "related", "args": ["A", "B"]}
  },
  "predicate_definitions": {
    "kinship": {"protocol": "kinship", "version": 1},
    "avatar": {"protocol": "pact", "version": 1},
    "related": {"protocol": "rules", "version": 2}
  }
}

The same rule, written so a parser can walk it.

Two further sketches, also in v2 shape, to show what becomes possible.

Transitive relation:

IF related(A,B) AND related(B,C) THEN related(A,C)

If A is related to B, and B is related to C, then A is related to C. A reader applying both this rule and the first one against the current chain would derive a richer set of pairs than the kinship inscriptions alone state.

Active avatar:

IF avatar(A) AND has_transitions(A) THEN active(A)

An avatar with at least one transition is active. The predicate active is introduced by this rule itself — it does not exist in PACT. New predicates can be brought into the world by the rules that define them.

v1 RULES inscriptions remain valid forever. v2 is one possible elaboration. Other elaborations are possible. The wall does not require any of them; readers do.

How to write your own rule

Anyone can inscribe a rule. There is no permission and there is no canonical authority. The wall accepts what is inscribed, and readers choose which rules to apply.

Pick a rule_id. A short stable name, hyphen-separated, that you will not change later. The first rule is kinship-implies-relation. Yours might be transitive-kinship, or recognised-by-recognised, or whatever the rule actually does.

Write the expression. Plain logical English with named predicates and capital-letter variables. Keep it readable. If a sentence describes the rule, that sentence should match the expression closely.

Name the predicates and where they come from. avatar comes from PACT. kinship comes from KINSHIP. acknowledges comes from LINEAGE. New predicates introduced by the rule itself — like related, or active — belong to RULES.

Write a note. One or two sentences. What does the rule do, and why. The note is the only field that speaks to a future reader who has no other context.

Inscribe as a fresh-sat inscription. The envelope is JSON, application/json, in an Ordinals envelope. No bitmap district binding, no preserved-sat flow needed. The rule stands on its own.

The wall holds it from then on. Whether a rule matters depends on who applies it, who builds on it, and who contests it. That is no different from how rules in any other public system work.

Open questions

A few things are not yet decided, and may stay open by design.

Conflict semantics. If two rules give contradictory conclusions, no resolution is specified. A reader can apply both and see the divergence; a reader can choose one rule set over another; a reader can leave the contradiction unresolved. The wall does not arbitrate.

Predicate ownership. Anyone can introduce a new predicate by writing a rule that uses it. Two rules can use the same predicate name to mean different things. There is no central registry. Readers will need to look at predicate_definitions to know which protocol-version a predicate belongs to.

Recursion. The shape sketched above does not place limits on recursion. A practical reader will need to choose them — depth bounds, fact-set-size bounds, or termination heuristics. The protocol does not prescribe these.

Evaluator implementations. No reference reader yet exists. The protocol-reader at /Users/wiardvasen/protocol-reader/ will be extended. Others may write their own. Different readers may produce different derivations from the same rule set; that is the point, and the test.

These are choices the community will make, or not make, by inscribing further rules and writing readers. The wall holds the artefacts. The reasoning is what humans and machines do with them.

The complete formal specification of the three protocols described above — KINSHIP, LINEAGE, and RULES — is available as a PDF document. It includes the envelope forms, validity rules, evaluation procedures, intellectual context, boundaries, future extensions, pseudocode, and worked examples for each protocol.

Rules, Protocols and an Ontology on Ordinals, Bitcoin (PDF) — Wiard Vasen, May 2026.