# 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 `` throughout. * **Update** — has `P:`. Modifies an existing beacon. Only the keys present are changed; absent keys keep their previous value. ## 4. Keys ### 4.1 Genesis | Key | Req | Meaning | Limit | |-----|-----|---------|-------| | `T` | yes | Profile token — which vocabulary the six lines use (§6) | `[A-Z0-9]{2,16}` | | `ID` | yes | `SCHEME:VALUE` — the identifier this beacon is about (§5) | value ≤ 128 | | `N` | yes | Display name / label | ≤ 64 chars | | `1` | no | Standard information line 1 | ≤ 200 chars | | `2` | no | Standard information line 2 | ≤ 200 chars | | `3` | no | Standard information line 3 | ≤ 200 chars | | `4` | no | Standard information line 4 | ≤ 200 chars | | `5` | no | Standard information line 5 | ≤ 200 chars | | `6` | no | Standard information line 6 | ≤ 200 chars | | `S` | no | Status code (§7). Default `ACTIVE` | token | | `A` | no | Delegated authority address (§8) | Dogecoin P2PKH address | | `U` | no | A URL for more information | ≤ 200 chars | 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 | Key | Req | Meaning | |-----|-----|---------| | `P` | yes | Genesis txid being updated (64 lowercase hex chars) | | any genesis key | no | The new value for that key | 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}`. | Scheme | Meaning | Validation | |--------|---------|------------| | `ISO11784` | FDX-B pet microchip (ISO 11784/11785) | exactly 15 digits | | `ISO11785` | alias of `ISO11784` | exactly 15 digits | | `AVID` | AVID pet microchip | 9 or 10 digits | | `TROVAN` | Trovan pet microchip | 10 digits | | `HOMEAGAIN`| HomeAgain 10-digit chip | 10 alphanumeric | | `SERIAL` | manufacturer serial number | ≤ 128 chars | | `VIN` | vehicle identification number | 17 alphanumeric | | `IMEI` | mobile device | 15 digits | | `MAC` | network hardware address | 12 hex, optional separators | | `EPC` | GS1 electronic product code | ≤ 128 chars | | `UUID` | RFC 4122 UUID | canonical 8-4-4-4-12 | | `URI` | any URI that identifies the thing | ≤ 128 chars | | `CUSTOM` | anything else | ≤ 128 chars | 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` | Line | Meaning | Suggested label | |------|---------|-----------------| | 1 | Species, breed, size | Species & breed | | 2 | Distinguishing appearance | Markings & description | | 3 | The person responsible for the animal | Guardian | | 4 | How to reach that person right now | Contact | | 5 | Where the animal lives | Home area | | 6 | Anything a finder must know | Notes (medical, reward) | ### `ASSET` | Line | Meaning | Suggested label | |------|---------|-----------------| | 1 | Class, make, model | Class & model | | 2 | Distinguishing features, condition | Identifying features | | 3 | The party accountable for the asset | Custodian | | 4 | How to reach that party | Contact | | 5 | Assigned site or location | Site | | 6 | Handling, compliance, recovery instructions | Notes | 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 | Code | Meaning | `PET` label | `ASSET` label | |------|---------|-------------|---------------| | `ACTIVE` | normal custody | Home | In service | | `MISSING` | lost, sought | Missing | Missing | | `RECOVERED` | found and returned | Found | Recovered | | `RETIRED` | no longer in service / deceased | Passed on | Retired | | `TRANSFERRED` | responsibility moved to someone else | Rehomed | Transferred | 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 `` element, a BEACON block: ``` BEACON/1 CERT P: ID:: N: ``` 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:` 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: | Target | Encodes | |--------|---------| | `txid` | the genesis txid as plain text | | `resolver` | `https:///r/` | | `explorer` | a block-explorer URL for the genesis txid | | `contact` | a `tel:` or `mailto:` URI taken from line 4 | | `url` | the record's `U` value | | `custom` | any URI supplied by the minter | 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.