BEACON/1 — a plain-text ownership and lost-and-found record protocol

Status: draft-1, 2026-08-08. Chain: Dogecoin (doginal / ord-style inscription). Content type: text/plain;charset=utf-8.

0. Why this exists

A pet microchip is a number. The number is useless on its own — it only means something because some company keeps a row in a database that maps the number to a person who can be phoned. When that company goes bankrupt, the number survives and the mapping does not. Every animal already carrying that chip is, from that moment, carrying a dead pointer. The owners are told to re-register with a successor registry, and the ones who don't hear about it, or don't get around to it, have a pet with a chip that resolves to nothing. The animals lost during that window get scanned, and the scan comes back empty.

BEACON is the smallest thing that fixes that: write the mapping somewhere that cannot go out of business. A record is plain text, inscribed on Dogecoin. It is readable by a person looking at raw chain data with no tooling, parseable by a few lines of code in any language, and it does not depend on this project, this website, or any company continuing to exist.

Nothing here is pet-specific. A pet microchip is one identifier scheme among many; a serial number, a VIN, a MAC address and a shipping-container number are the same problem wearing different clothes. The protocol is written generically and the pet vocabulary is one profile (§6).

1. Design rules

1. Plain text, line-oriented. No JSON, no CBOR, no length prefixes. If you can read the inscription, you can read the record.
2. Small. A record should fit in one commit/reveal pair. Target ≤ 1000 bytes.
3. Forward compatible. An unknown key is preserved and ignored, never an error.
4. The chain is the record. Indexes, websites and APIs (including this project's) are caches. Anyone may build a competing indexer from the chain alone; §5 and §7 are complete enough to do it.
5. Authority comes from custody of the inscription, not from an account on a server (§8).

2. Encoding

• UTF-8, no BOM.
• Lines separated by LF (0x0A). A trailing CR (0x0D) is stripped.
• Leading and trailing spaces/tabs on a line are stripped.
• Blank lines are ignored.
• A line whose first non-space character is # is a comment and is ignored.
• Line 1 (the first non-blank, non-comment line) MUST be exactly BEACON/1. This is the magic. A payload that does not start with it is not a BEACON record.

Every subsequent line is:

KEY:VALUE

KEY matches [A-Z0-9]{1,8}. VALUE is the rest of the line after the first colon, with one optional leading space stripped. A VALUE may itself contain colons (ID:ISO11784:985141001234567 — key ID, value ISO11784:985141001234567).

A line with no colon, or an out-of-charset key, is ignored (rule 3), not fatal.

Duplicate keys: the first occurrence wins. Later duplicates are ignored. This makes truncation-at-the-end safe and makes parsing order-independent.

3. Record kinds

There are two kinds, distinguished by the presence of P:

• Genesis — no P key. Creates a beacon. Its reveal txid is the beacon's permanent identity, written <txid> throughout.
• Update — has P:<genesis txid>. Modifies an existing beacon. Only the keys present are changed; absent keys keep their previous value.

4. Keys

4.1 Genesis

The six numbered lines are the information standard: six slots, always six, always in the same order, whose meaning is fixed by the profile and whose labels are a presentation choice. Six is a deliberate constraint — it is enough to identify a living thing or an object to a stranger holding it, and few enough that a record stays cheap and a reader stays willing.

4.2 Update

An update MAY carry T and ID, but a reader MUST reject an update that changes ID to a different identifier than the genesis — the identifier is what the beacon is. Changing T is likewise rejected.

4.3 Reserved

X (cross-reference to another beacon txid), C (certificate/NFT txid, §9), M (free-form machine-readable extension, one key=value; list). Readers that do not implement them must preserve and ignore them.

5. Identifier schemes

ID is SCHEME:VALUE. SCHEME is [A-Z0-9]{2,16}.

A reader encountering an unregistered scheme MUST accept the record and treat the identifier as opaque. Scheme validation is a warning surface for the writer, not a reason to refuse to read the chain.

Normalisation for lookup: compare SCHEME case-insensitively after upper-casing, and compare VALUE after stripping spaces, dashes and dots. So ISO11784:985 141-001.234567 and iso11784:985141001234567 are the same beacon subject. Records are stored as written; normalisation applies only to matching.

6. Profiles — what the six lines mean

A profile fixes the semantics of lines 1–6 and supplies the display labels. Two profiles are defined in BEACON/1.

PET

ASSET

Both profiles carry the same shape: what it is, how to recognise it, who is responsible, how to reach them, where it belongs, what else to know. That shape is the actual standard; PET and ASSET are two vocabularies over it. New profiles SHOULD preserve it.

7. Status codes

Status changes are made by inscribing an update record (§3) carrying P and S. A reader MUST accept any unknown status token and display it verbatim.

8. Authority — who may update a beacon

The holder of the genesis inscription output is the authority. A doginal is a specific 0.001-DOGE output; whoever controls the address holding it controls the beacon. This is the whole access-control model. There is no account, no password, no registrar.

An update is honoured iff it was inscribed by:

• the address that held the genesis inscription at the time the update confirmed, or
• the address named in the genesis record's A key (delegated authority), if present.

An update from any other address is recorded but not applied — an indexer MUST show it as unauthorised rather than silently discarding it, so that a disputed record is visible rather than invisible.

Consequences the writer must understand, stated plainly:

• Transferring the inscription transfers the beacon. Selling or sending the doginal hands the next holder the right to rewrite the record. That is the intent: for an asset, custody of the token is custody of the registration.
• Losing the key freezes the record. The record stays readable forever; it can never be updated again. Mint a new genesis and cross-reference it with X.
• Nothing here is private. Everything inscribed is public and permanent. §11 says what not to write.

9. Certificates (optional NFT)

A beacon MAY additionally be minted as a visual certificate — a second inscription whose content type is image/svg+xml. It is decorative and evidentiary; it is not required to read or resolve a beacon.

A certificate MUST embed, inside the SVG's <desc> element, a BEACON block:

BEACON/1 CERT
P:<genesis txid>
ID:<scheme>:<value>
N:<name>

so that the certificate is self-describing and an indexer can link it back to the record without trusting a filename. The genesis record MAY be updated with C:<certificate txid> to point forward at it.

A certificate MAY carry a QR code. What the QR encodes is the minter's choice and MUST be one of:

A resolver URL points at a resolver. It is a convenience, not the record. If the resolver is gone, the txid inside the certificate still resolves against the chain.

10. Wire format on Dogecoin

BEACON uses the ordinary doginal (ord-style) envelope, unchanged, so that every existing Dogecoin inscription indexer already sees BEACON records without modification. For completeness, an independent implementer needs:

• The payload is pushed as a chunk sequence inside P2SH redeem scripts, revealed across a chain of transactions: push("ord"), push(nParts), push(contentType), then for each part: push(partsRemaining), push(partBytes), with parts of ≤ 240 bytes.
• The final reveal transaction sends a 0.001 DOGE output (index 0) to the owner. That output is the inscription, and its txid is the beacon identity.
• To read a record: start at the reveal txid, walk input 0 back through the P2SH chain, collect each scriptSig's leading data pushes (everything before the final two pushes, which are the signature and the redeem script), reverse the per-transaction order, then decode the chunk sequence above.

An indexer looking for BEACON records scans inscriptions whose content type is text/plain* and whose first line is BEACON/1. That is the entire discovery rule.

11. What must not be written

Permanent and public are the same sentence here.

• No home street address. Line 5 is an area — a town, a postcode, a site name.
• No government identity numbers, no payment details, no passwords.
• Use a contact channel you are willing to keep or abandon: a phone number, an email address, or a URL you control. It is permanent once written.
• An update can supersede information but cannot erase it. Assume everything ever written stays readable.

12. Worked example

Genesis, PET profile:

BEACON/1
T:PET
ID:ISO11784:985141001234567
N:Biscuit
1:Beagle mix, 24 lb, tan and white
2:White blaze, notched left ear, red collar with a bell
3:H. Elsner
4:+1-650-649-4265
5:San Jose, CA
6:Diabetic, needs insulin twice daily. Reward for safe return.
S:ACTIVE

Reported missing, three months later:

BEACON/1
P:6f1c9a2b...e4
S:MISSING
5:San Jose, CA — last seen near Almaden Lake, 2026-11-02
6:Diabetic, needs insulin twice daily. Reward. Call any hour.

Home again:

BEACON/1
P:6f1c9a2b...e4
S:RECOVERED
5:San Jose, CA

The same three records under the ASSET profile would read T:ASSET, ID:SERIAL:AX-40021, N:Fusion splicer #3, and the reader would label line 3 "Custodian" instead of "Guardian". Same protocol, same bytes, different vocabulary.

13. Versioning

The magic carries the version. BEACON/2 would be a new magic and a new document. Within BEACON/1, new keys, new profiles and new identifier schemes may be added without a version bump, because rule 3 guarantees an old reader survives them.