# Decision log Newest first. Each entry: what was decided, by whom, why, and what it invalidates. --- ## D-002 — Target chain changes from Litecoin to Pepecoin (2026-09-10) **Decided by:** Martin. > "Cancel the light coin install. Let's work on Pepe coin but not inscriptions like Doge's. > Inscriptions like using Omni. I think there are better features with Omni like the check sum > validator and built-in token exchange" **Action taken:** Litecoin Core install cancelled and fully removed (binaries, datadir, staged tarballs). Nothing was left on disk; 416 GiB free, same as before we started. **What this invalidates:** - Phase 2 as originally written (recovering Martin's 2021-2023 Omni inscriptions from Litecoin) is **suspended, not impossible**. See "Recovery is not lost" below. - Phase 3's plan to validate our consensus engine against a live OmniLite reference node. **What survives unchanged:** Phase 1 Omni research. The Omni protocol sources (OmniLite, Omni Core, the spec) remain the ground truth regardless of which chain we deploy on. --- ## D-001 — Proceed on the 5400 RPM HDD; blockfilterindex disabled (2026-09-10) Superseded in part by D-002. Machine survey remains valid. --- # Feasibility: can Omni run on Pepecoin? **Verdict: yes.** Omni is a meta-layer, not a chain feature — it is a payload encoding plus off-chain consensus rules, interpreted by an indexer. It needs no forked node, only a node whose transaction policy will relay the payload-carrying outputs. All of the following are ***verified in source code***, from `github.com/pepecoinppc/pepecoin` at tag **v1.1.0** (commit `4fb5a0cd`, 2024-12-16), cloned to `/home/martin/reference/pepecoin`. | Requirement | Pepecoin v1.1.0 | Source | Verdict | |---|---|---|---| | **Class C** — `OP_RETURN` data output | `MAX_OP_RETURN_RELAY = 83` bytes (80 usable payload) | `src/script/standard.h:30` | ✅ identical to BTC/LTC | | Data carrier relayed by default | `DEFAULT_ACCEPT_DATACARRIER = true` | `src/script/standard.h:16` | ✅ | | Data size tunable | `-datacarrier`, `-datacarriersize` | `src/init.cpp:483-484,1094-1095` | ✅ | | **Class B** — bare multisig relayed | `DEFAULT_PERMIT_BAREMULTISIG = true` | `src/validation.h:143` | ✅ | | Bare multisig standardness | `x-of-3` accepted as standard | `src/policy/policy.cpp:41-48` | ✅ exactly what Class B needs (1-of-3) | | Dust limit (soft) | `DEFAULT_DUST_LIMIT = RECOMMENDED_MIN_TX_FEE` = **0.01 PEP** | `src/policy/policy.h:70`, `:23` | ✅ cheap | | Dust limit (hard, standardness) | `DEFAULT_HARD_DUST_LIMIT = DUST/10` = **0.001 PEP** | `src/policy/policy.h:81` | ✅ tunable via `-harddustlimit` | | Recommended min fee | `RECOMMENDED_MIN_TX_FEE = COIN/100` = **0.01 PEP** | `src/policy/policy.h:23` | ✅ | | Coin precision | `COIN = 100000000` (8 decimals) | `src/amount.h:18` | ✅ same as BTC/LTC | **Other chain parameters** (*verified in source code*, `src/chainparams.cpp`): | Parameter | Value | Line | |---|---|---| | Block spacing | **60 seconds** (Litecoin is 150 s, Bitcoin 600 s) | `:89` | | Subsidy halving interval | 100,000 blocks | `:78` | | AuxPoW (merged mining) from height | 42,000 | `:136` | | AuxPoW chain ID | `0x003f` (63) | `:119` | | Mainnet P2P port | 33874 | `:153` | | Testnet P2P port | 44874 | `:282` | | Regtest P2P port | 18444 | `:392` | **Consequence of 1-minute blocks:** inscription chunks confirm ~2.5x faster than on Litecoin and ~10x faster than Bitcoin. Good for multi-chunk file inscription, which is inherently serial across many transactions. --- # Corrections to two assumptions in the pivot Martin cited "the check sum validator and built-in token exchange" as reasons to prefer Omni. Both features are real, but one does not do what the name suggests. ### 1. Omni's "consensus hash" validates ledger state, not file content `omni_getcurrentconsensushash` hashes the **entire Omni ledger** (balances, properties, offers) at a given block, so two independent implementations can prove they agree. It is an implementation-agreement check. It is **not** a per-inscription content checksum, and it will not tell you whether a recovered JPEG is intact. A content hash is still the right idea — it was already in the Phase 4 v2 spec ("a SHA-256 hash of the content"). That is ours to design; Omni does not supply it. *Label: assumption pending Phase 1 verification against `consensushash.cpp`.* ### 2. The "built-in exchange" trades token ↔ base currency, probably not token ↔ token Omni's **DEx** (types 20 offer / 22 accept) sells a token for the chain's native coin — so on Pepecoin, token ↔ PEP. That works and transfers cleanly. Omni Core on Bitcoin additionally has **MetaDEx** (types 25-28) for token ↔ token trading. The transaction-type list Martin compiled from OmniLite does **not** include 25-28, which suggests OmniLite lacks MetaDEx. If token-to-token trading matters, that capability may have to be ported from Omni Core rather than OmniLite. *Label: assumption — must be confirmed in Phase 1 against `src/omnicore/omnicore.h`.* --- # The significant new risk: no reference implementation On Litecoin, OmniLite exists. Our engine could be proven correct by replaying real mainnet history and comparing `omni_getcurrentconsensushash` against a reference node at every block. **On Pepecoin there is no Omni, so there is no oracle.** We would be the first and only implementation, defining truth with no independent way to catch our own consensus bugs. Also: on day one the DEx has no counterparties, and we must define our own genesis parameters (activation height, Exodus-equivalent address, ecosystem IDs). **Mitigation — and it removes the need for any 217 GiB sync:** OmniLite ships unit tests (`src/omnicore/test/`) and functional tests (`test/functional/omni_*.py`) that run on **regtest**. Those are executable, authoritative test vectors for the Omni rules, and they need no mainnet chain at all. Building our engine against that suite gives real correctness validation on this modest hardware. This was already the Phase 3 plan; it now carries more weight because it is our *only* oracle. # Recovery is not lost Martin's 2021-2023 files are still in Litecoin blocks and are not going anywhere. Omni's encoding (Class B / Class C, the payload layouts) is **chain-independent**, so if the extractor is written chain-agnostically from the start — chain params, genesis height and Exodus address as configuration, not constants — recovering them later costs a Litecoin sync and a config file, not a rewrite. **Design requirement adopted:** every component we build takes chain parameters as config. No hard-coded Pepecoin assumptions. --- ## D-003 — App scope decisions (2026-09-10) Decided by Martin: | Question | Decision | |---|---| | First feature after the M0-M2 foundation | **M3 MetaDEx exchange** | | Protocol marker (Class C, replaces Omni's `omni`) | **`pepo`** | | Crowdsales, types 51/53 | **In scope** | Marker note: `pepo` is consensus-critical. It can change freely before launch; after the first mainnet inscription it cannot change without splitting state. --- # ⚠️ MetaDEx constraints that affect the order-book design *Verified in source code*, `omnicore/src/omnicore/tx.cpp:1643-1666` (`logicMath_MetaDExTrade`): | Rule | Code | Consequence | |---|---|---| | Both sides are **property IDs** (`u32`) | payload layout, `createpayload.cpp:486` | **The native coin is not a property. MetaDEx cannot quote PEP.** | | Non-fungible properties rejected | `isPropertyNonFungible(...)` → `PKT_ERROR_TOKENS -27`, `:1653` | **NFTs cannot trade on MetaDEx at all** | | `property != desired_property` | `:1658` → `PKT_ERROR_METADEX -29` | no self-pairs | | Both sides same ecosystem | `isTestEcosystemProperty(...)`, `:1666` | main and test books never mix | | Type must be permitted for that property at that block | `IsTransactionTypeAllowed(...)`, `:1643` | activation rules are per-property | ## What this means in practice **A TOKEN/PEP market with real bids and asks is not possible on MetaDEx.** Token ↔ native coin is DEx only (types 20/22), which is **one-sided sell offers** — an offers list, not a book. This is not an oversight in Omni; it is how Omni is structured. Omni's answer was a **base property**: property 1 (`OMNI`) is a token, so every pair `TOKEN/OMNI` is a genuine two-sided MetaDEx book, while `OMNI/BTC` is handled by the one-sided DEx. For us the same shape applies: we need a **base property** — call it property 1 — against which all MetaDEx pairs quote. Which raises the question Omni answered in 2013 with the Exodus crowdsale: **how does property 1 come into existence and get distributed?** Options: 1. **Crowdsale (type 51).** Send PEP to the issuer during a window, receive base tokens. This is literally what Omni did, and crowdsales are now in scope (D-003). 2. **Burn-to-mint.** Send PEP to the Exodus-equivalent address, receive base tokens at a fixed ratio. Simple, permissionless, ongoing, no issuer trust. 3. **Fixed issuance (type 50)** to a treasury address, distributed manually. Simplest to build, most centralised, weakest story. 4. **No base property.** Accept that only DEx (one-sided, token↔PEP) exists. Much weaker than what Martin asked for. **Second open problem: NFTs cannot trade on MetaDEx** (`:1653`). Selling an NFT therefore needs either the DEx path or a mechanism we design. Flagged for M4. --- ## D-004 — Protocol shape (2026-09-10) Decided by Martin: | Question | Decision | Consequence | |---|---|---| | Base property (property 1) origin | **Burn-to-mint** | Send PEP to the Exodus-equivalent address, receive base tokens at a fixed ratio, permanently open. No issuer trust, no deadline, no premine. Gives the base token a hard PEP cost floor. | | NFT sales | **Extend DEx (20/22) to accept non-fungible ranges** | Deliberate, documented divergence from Omni Core, which rejects NFTs on MetaDEx (`tx.cpp:1653`) and has no NFT DEx path. Must be spec'd and tested as our own rule. | | Activation height | **Set at launch, ~tip + 1 day** | Left unset in config until M7. Indexer backlog stays at zero through development. | | Ecosystems | **Keep both (main + test)** | Mirrors Omni ID ranges; gives an on-mainnet sandbox that never mixes with the main book. | ### Consequences that now need specifying 1. **Burn-to-mint is a new transaction path with no Omni equivalent.** Omni's Exodus output is a *marker* for Class B, not a value sink. We are giving it a second meaning: PEP sent to it mints base tokens. These two roles must not collide — a Class B marker output must not accidentally mint. Needs an explicit, tested rule (e.g. minting only on an output that is the sole payment to Exodus in a transaction carrying no Omni payload, or a dedicated mint transaction type). 2. **NFT-on-DEx is our own consensus rule.** No reference implementation exists for it, so it carries the same "no oracle" risk as everything else, and needs its own test vectors. --- ## D-005 — Name, economics, signing, scope (2026-09-10) Decided by Martin: | Question | Decision | |---|---| | **Project name** | **Ribbit** | | **Class C marker** | **`rbit`** (0x72 0x62 0x69 0x74) — **supersedes `pepo` from D-003** | | Base token | **1 PEP = 1 RBIT**, divisible (8 dp), **uncapped**, minted by burn-to-mint only. No premine. | | Signing | **Node wallet RPC** — app builds payload, `pepecoind` funds and signs via `fundrawtransaction` / `signrawtransaction`. Keys never enter our process. | | Litecoin recovery (old Phase 2) | **Dropped.** | ### Effect of dropping Litecoin recovery This is a real simplification, not just a deletion: - **No v1 format reader.** The 4×255-char base64-in-type-50-text-fields format, and all its quirks (stray `'`, extra/missing `=`), leave the spec entirely. Inscriptions are **v2 only**. - **No chain-agnostic requirement.** The design constraint adopted in D-002 is withdrawn. Chain parameters still live in config rather than as literals — that is ordinary good practice — but we no longer carry portability as a goal or test it. - Martin's 2021-2023 files stay where they are, in Litecoin blocks. They are not going anywhere, but reversing this decision later would mean building the v1 reader and a Litecoin sync from scratch, not flipping a flag. ### Burn-to-mint, settled parameters - Ratio **1:1**, divisible, uncapped, permanently open — no deadline, no cap, no issuer. - Every RBIT therefore has a hard floor of 1 burned PEP behind it. - Still to specify (see D-004): the rule that separates a **minting** payment to the Exodus address from a Class B **marker** output, so a Class B transaction can never mint by accident. --- ## D-006 — Openness, access, feature scope (2026-09-10) | Question | Decision | |---|---| | Spec and code | **Public from the start** | | Web UI binding | **127.0.0.1 only** — reach remotely via SSH port-forward | | Base token ticker | **RBIT** | | Delegates (73/74) | **In scope** | | Freezing (71/72/185/186) | **In scope** | | Send-to-owners (3) | **In scope** | | Restricted send (2) | **Out of scope** | **Why public matters more than it looks:** a second independent implementation is the only genuine oracle for consensus correctness, and that can only exist if the spec is public. This partially answers the "no reference implementation" risk from D-002 — not immediately, but it is the only path that ever resolves it. **Why localhost-only matters:** the app can trigger signing through the node wallet (D-005), so exposing the UI exposes spending authority. Localhost is the correct default and costs nothing, since SSH port-forwarding covers remote use. --- ## D-007 — No base token; burn-to-mint removed (2026-09-10) **Decided by Martin:** no base token at all. **Supersedes D-004 and D-005 on this point.** ### What prompted it Martin asked: *"If the Pepe is burned when the rbit is created, how would somebody convert their RBIT back to Pepe?"* **They cannot.** Ribbit is a sidecar meta-layer with **no consensus power over PEP** — only a private-key holder can move PEP. Burning means sending to an address with no key, so the protocol can never release it. This is structural. **No design gives trustless redemption of the base coin**; any redemption requires a custodian holding real PEP. (Omni itself was custodial here: its Exodus address held real BTC controlled by the foundation, not burned.) ### Correction to an earlier claim of mine D-005 recorded that burn-to-mint gives RBIT *"a hard floor of 1 burned PEP."* **That was wrong, and backwards.** Under uncapped 1:1 minting: - 1 PEP is a permanent **ceiling** — nobody pays more than 1 PEP for something they can mint at 1 PEP. - With no redemption there is **no floor whatsoever**. - Secondary demand is ~zero, since anyone needing the token mints rather than buys, so holders can only exit by undercutting. A quote asset is precisely what traders hold *between* trades, so this would have taxed every user of the order book. Dropping it is the right call. ### What this removes | Removed | Effect | |---|---| | RBIT the token, property 1 | no base/quote asset ships with the protocol | | Burn-to-mint | **the Exodus address reverts to being purely a Class B marker, as in Omni** | | Exodus dual-meaning rule | the "marker vs value sink" collision problem (D-004) disappears entirely | | One of two unreferenced divergences | only NFT-on-DEx remains as novel consensus code | Net: meaningfully less consensus surface, and less of it unvalidated. "Ribbit" and the `rbit` marker are unaffected — they name the protocol, not a token. ### What the exchange looks like now | Pair | Mechanism | Book shape | |---|---|---| | token ↔ token | **MetaDEx (25-28)** | **genuine two-sided book**, bids and asks | | token ↔ PEP | DEx (20/22), payment window | one-sided sell offers | | NFT ↔ PEP | DEx, extended for ranges (D-004) | one-sided listings | No canonical quote asset ships. If the market converges on one — a wrapped-PEP or a stablecoin issued by a participant — it becomes the de-facto quote asset without us blessing it. That is a defensible position: we provide the venue, not the money. ### Implementation notes 1. **Property IDs 1 and 2 are special-cased in Omni** as `OMNI_PROPERTY_MSC` / `OMNI_PROPERTY_TMSC` (*verified in source*, `omnicore.h:123-124`). With no base token these are free. Decision: leave 1 and 2 **permanently reserved and unassigned**, user properties start at 3. Costs nothing and keeps a slot if a base token is ever revisited. 2. **Ported Omni test vectors assume OMNI/TOMNI exist.** Any vector that funds an account with property 1 or 2 needs adaptation. Expect friction in M2-M3 test porting; budget for it. --- ## D-008 — Crowdsales dropped (2026-09-10) **Decided by Martin:** remove types 51 (create property variable / crowdsale) and 53 (close crowdsale) from scope. **Supersedes D-003.** **Rationale:** a crowdsale's payload carries `propertyIdDesired` (*verified in source*, `createpayload.cpp:228-239`) — it can only be funded with **another property**, never the native coin. With no base token (D-007), there is nothing to fund the first crowdsale with. Keeping them would have meant either shipping a feature that cannot be used, or adding a second novel consensus rule (native-coin crowdsale funding) immediately after deleting one. **Removed:** bonus math, deadlines, early-close rules, issuer-percentage handling, and the crowdsale-participation code path in state processing. A meaningful slice of M6. **Consensus-hash note:** `GetConsensusHash()` has a crowdsale section (*verified in source*, `consensushash.cpp:232-234`). We keep the section in our implementation but it will always be empty, so it contributes nothing. Documented so that re-adding crowdsales later does not change the hash of existing state. **Reversible?** Yes, cleanly. Crowdsales touch property creation and balances but nothing else depends on them. --- ## D-009 — Encrypted messaging: integration and carrier (2026-09-11) Decided by Martin. | Question | Decision | |---|---| | Where it lives | **Inside Ribbit** — a Ribbit message type sharing the payload codec, Class B/C encoding, indexer, reorg handling and database | | Primary carrier | **Class B** (7,646 bytes/tx), **Class C** for messages fitting in 72 bytes | | Messages > 7,646 bytes | **Chained Class B with a countdown index**, using the Doginals UTXO-chaining mechanism | ### Correction: the 25-transaction limit is not a ceiling I had cited Pepecoin's 25-ancestor mempool limit as an argument against OP_RETURN chunking. **Martin pointed out this is wrong**, and he is right: the limits are on **in-mempool** ancestors (`init.cpp:437`, `:439`), and `removeForBlock` (`txmempool.h:554`) drops mined transactions from the mempool, so a confirmation resets the count. Send 25, wait one block (~60 s), send 25 more. It is a throughput constraint, not a ceiling. The real arguments for Class B are **atomicity** and **cost**: - A single-transaction message either confirms whole or not at all. A 16-transaction message has 16 chances to half-land, and a partial message is on-chain **permanently** — unreadable but not removable. - It removes an entire category of design: no chunk index, count, gap detection, reassembly or chaining for anything under ~7,598 characters. - ~0.022 PEP in one transaction versus ~0.04 PEP across sixteen. ### A size limit that binds before the count does *Verified in source*, `validation.h:76,80`: `DEFAULT_ANCESTOR_SIZE_LIMIT = DEFAULT_DESCENDANT_SIZE_LIMIT = 101` kB. An unconfirmed chain is capped at ~101 kB **regardless of transaction count**. Irrelevant on the OP_RETURN path (25 × ~250 B ≈ 6 kB, so the count binds first), but decisive for chained Class B: at ~14.7 kB per full transaction only **~6** can chain unconfirmed, not 25. Martin's batch-and-wait strategy applies exactly here. --- # What Doginals does, and what we take from it Read from Martin's own `github.com/martinseeger2002/doginals`, `doginals.js:434-560`. ```js MAX_CHUNK_LEN = 240 // bytes per data push MAX_PAYLOAD_LEN = 1500 // bytes per transaction ``` 1. Data is split into 240-byte chunks. The inscription script is `'ord'`, chunk count, content type, then `(index, chunk)` pairs where the index **counts down**: `parts.length - n - 1`, so **the final chunk carries index 0**. 2. Chunks are packed into ~1500-byte partials, one per transaction. 3. Each transaction creates a **P2SH output** committing to its partial. The redeem script is only ` OP_CHECKSIGVERIFY OP_TRUE`. 4. The **next** transaction spends it, and the data rides in that transaction's **scriptSig** as plain pushes, which the `OP_DROP`s discard. ### Why 1500 is not arbitrary *Verified in source*, `pepecoin/src/policy/policy.cpp:78-93`: ``` scriptSig.size() > 1650 -> "scriptsig-size", non-standard !scriptSig.IsPushOnly() -> "scriptsig-not-pushonly" ``` plus `MAX_SCRIPT_ELEMENT_SIZE = 520` (`script.h:22`). So ~1500 bytes of data, a ~72-byte signature and a ~40-byte redeem script land just under 1650. The constant is tuned precisely to that ceiling. **The technique is mainnet-standard on Pepecoin.** ### The two properties worth stealing - **Ordering is enforced by the UTXO chain, not by trusting an index.** A chunk cannot be reordered or skipped, because each transaction spends the previous one's output. Only whoever holds that output can extend the chain — which is the sender binding the brief wanted from change-chaining, except structural rather than conventional. - **Completion is self-describing.** The countdown reaching 0 *is* the terminator. An abandoned chain never reaches 0, so an incomplete message is always distinguishable from a complete one — no separate seal transaction, no ambiguity. ### Carrier comparison | Carrier | Bytes/tx | Atomic | Ordering | Mainnet-standard | |---|---|---|---|---| | Class C (OP_RETURN) | 72 | ✅ | needs index | ✅ | | **Class B (multisig)** | **7,646** | ✅ ≤7,646 | n/a, single tx | ✅ | | Doginals P2SH | ~1,500 | ❌ | **UTXO chain** | ✅ | **Decision: borrow the mechanism, not the carrier.** Chained *Class B* with a countdown index gives Doginals' structural ordering and self-describing completion while carrying **5× more data per transaction**. ### Resulting shape | Message size | Carrier | Chunking machinery | |---|---|---| | ≤ 72 bytes | Class C, one transaction | none | | ≤ 7,646 bytes | **Class B, one transaction** | **none** | | larger | chained Class B, countdown index | chunk header only on this path | --- ## D-010 — The Messenger is testnet-only, permanently (2026-09-11) **Decided by Martin:** *"The Messenger part of the application should always use testnet."* This is a **permanent product rule**, not a testing phase. Encrypted messaging never operates on mainnet. ### What this changes | Area | Effect | |---|---| | Network selection | The messaging code path **refuses to run against mainnet**, enforced in code rather than by configuration. A mainnet params object passed to a messaging function is an error, not an option. | | Mainnet standardness | Still designed for. Testnet does not enforce standardness (`fRequireStandard = false`, `chainparams.cpp:309`), so a transaction that only works there would be silently non-standard. Keeping to mainnet rules means the format stays honest and portable. | | Threat model | Testnet chains **can be reset or deep-reorged**. Messages are not durable. This must be stated plainly to users — it is a property of the medium, not a bug. | | Coins | Testnet PEP has no value, so fee estimates are informational only. | | Node | Requires a **second node** alongside the mainnet Ribbit node. | ### Why designing to mainnet limits still matters Testnet accepts non-standard transactions. Without the discipline of mainnet limits we would not discover that a format is unrelayable until someone tried it somewhere real. The regtest standardness check (`-acceptnonstdtxn=0`) in Step 4 is what actually proves it. --- ## D-011 — Renamed to DogecoinArcade; multi-chain (2026-09-11) **Decided by Martin:** *"Let's change the name of the application to DogecoinArcade. I know it's for Pepe, but it should also work on Doge in the exact same way."* | Item | Old | New | |---|---|---| | Project | Ribbit | **DogecoinArcade** | | Class C marker | `rbit` | **`arcd`** (0x61 0x72 0x63 0x64) | | Python package | `ribbit` | **`arcade`** | | Distribution name | `ribbit` | **`dogecoin-arcade`** | | Repo path | `~/ribbit` | `~/dogecoin-arcade` | **Entries D-001 through D-010 above still say "Ribbit".** They are left as written: a decision log that gets retroactively edited is not a record. Read "Ribbit" as "DogecoinArcade" in anything dated before 2026-09-11. The marker change was free because nothing has launched. **After the first mainnet transaction it would be impossible** — a marker change splits state. ### Relationship to the existing GitHub repo `github.com/martinseeger2002/DogecoinArcade` already exists and already contains encrypted messaging (`SendSms.py`, `DecryptSmsData.py`, `encrypt_data.py`, `callGetPubKey.py`). **Martin's decision: keep them entirely distinct.** This is a new project that shares a name; nothing is merged and nothing is pushed. --- # Dogecoin support: verified, and nearly free Verified against `github.com/dogecoin/dogecoin` at 1.14.99, cloned to `/home/martin/reference/dogecoin`. Every constant this protocol depends on is **identical** between Dogecoin and Pepecoin — same values, and the same source line numbers, because Pepecoin is a Dogecoin fork: | Constant | Value | Source (identical in both) | |---|---|---| | `MAX_OP_RETURN_RELAY` | 83 | `script/standard.h:30` | | `DEFAULT_ACCEPT_DATACARRIER` | true | `script/standard.h:16` | | `DEFAULT_PERMIT_BAREMULTISIG` | true | `validation.h:143` | | x-of-3 bare multisig standard | yes | `policy/policy.cpp:41` | | `COIN` | 100000000 | `amount.h:18` | | `RECOMMENDED_MIN_TX_FEE` | COIN/100 | `policy/policy.h:23` | | `DEFAULT_DUST_LIMIT` | = min fee | `policy/policy.h:70` | | `DEFAULT_HARD_DUST_LIMIT` | DUST/10 | `policy/policy.h:81` | | scriptSig standardness limit | 1650 | `policy/policy.cpp:86` | | `DEFAULT_ANCESTOR_LIMIT` / size | 25 / 101 kB | `validation.h:74,76` | | Block spacing | 60 s | `chainparams.cpp` | **Only chain identity differs:** | | Dogecoin | Pepecoin | |---|---|---| | mainnet P2PKH version | 30 (`D…`) | 56 (`P…`) | | mainnet P2SH version | 22 | 22 | | mainnet P2P / RPC | 22556 / 22555 | 33874 / 33873 | | testnet P2P / RPC | 44556 / 44555 | 44874 / 44873 | Because `Params` already holds exactly these fields, Dogecoin support cost **three new `Params` instances and zero code changes**. ### ⚠️ Testnet addresses are ambiguous between the two chains Dogecoin testnet and Pepecoin testnet both use `PUBKEY_ADDRESS = 113` and `SCRIPT_ADDRESS = 196`. **A testnet address cannot tell you which chain it is for.** Never infer the chain from an address; record it explicitly alongside any key announcement or message. Noted in `arcade/config.py` beside the params. ### Messaging guard `require_messaging_network()` enforces D-010 in code: messaging functions refuse any mainnet params object. `MESSAGING_NETWORKS` is `{test, regtest, doge-test, doge-regtest}`. --- # Martin's existing encryption, compared to the new brief Read from `github.com/martinseeger2002/DogecoinArcade`, `encrypt_data.py`. **Existing scheme:** secp256k1 ECDH → HKDF-SHA256 → AES-256-GCM key-wrap → AES-256-GCM data. | | Existing | Brief requires | |---|---|---| | Curve | secp256k1, using **wallet keys** | X25519, **separate from wallet** | | Construction | ECDH + HKDF + AES-GCM keywrap + AES-GCM | libsodium sealed box | | Envelope overhead | **93 bytes** (33 pubkey + 12 IV + 32 wrapped key + 16 tag) | **48 bytes** (32 ephemeral pubkey + 16 MAC) | The existing construction is cryptographically sound — ECDH+HKDF+AES-GCM is a legitimate KEM/DEM. Two reasons the new design still differs: 1. **45 bytes of pure overhead.** A sealed box derives the data key directly from the ECDH output instead of wrapping a separate AES key. On an 80-byte OP_RETURN that difference decides whether a short message fits at all. 2. **Wallet keys are the wrong keys.** Encrypting to a spending key welds messaging identity to spending authority: the key is exposed by every signature, cannot be rotated without moving funds, and its compromise reads every past message. Separate X25519 identity keys fix all three. --- ## D-012 — The application is permanently dual-chain (2026-09-11) **Decided by Martin:** *"the page should have both testnet and mainnet on it forever because we will be using testnet for messages and main for tokens and nfts and also pep transactions."* | Chain | Role | Sections | |---|---|---| | **Testnet** | Messenger | Inbox, Compose, Keys | | **Mainnet** | Ledger | Tokens, NFTs, Exchange, PEP transactions, Explorer | This is a permanent split, not a migration path. It supersedes the implicit assumption in the web UI that one network was selected at launch. ### Why the split makes sense Messages are **not durable**: testnet chains get reset and deep-reorged (D-010), and messages are conversational rather than assets. Tokens, NFTs and PEP balances **are** assets and belong on a chain nobody resets. Each side gets the chain whose properties match what it holds. It also means a bug in the messaging code can never touch real value, which is a stronger guarantee than any amount of care in the messaging code itself. ### The immediate constraint The mainnet node runs with **`disablewallet=1`** (docs/00-node-setup.md), chosen in Phase 0 because nothing then needed to sign. So mainnet is currently **read-only**: it can serve blocks, indexed token state and NFT state, but cannot send PEP or create a token. Enabling a mainnet wallet is a deliberate step Martin has to take, because that wallet holds real money. Until then the UI must show mainnet sections as read-only rather than failing obscurely at signing time. ### Guards that must hold 1. `require_messaging_network()` continues to refuse mainnet for anything in `arcade.messaging`. The dual-chain UI makes it *easier* to point a messaging call at the wrong node, not harder, so this matters more now, not less. 2. `verify_connected_chain()` runs on every connection, so a misconfigured datadir cannot silently cross the streams. 3. Every section states which chain it is acting on, in the interface itself. A user who cannot tell whether they are about to spend testnet or real coins is one misclick from a bad day. --- ## D-013 — The wallet is the identity; there is no passphrase (2026-09-11) **Decision.** The messaging identity is derived from a wallet address. There is no passphrase, no key file, and nothing for a user to write down. `wallet.dat` is the only thing they have to keep. ### What this replaces D-009 gave the messaging key its own passphrase, encrypted at rest with Argon2id. That was cryptographically sound and a poor product. The failure mode was absolute: forget the passphrase and every message ever sent to that identity is unreadable, by anyone, forever. Two attempts were made to soften it — generating the passphrase rather than letting the user invent one, then saving it on the machine so it could be looked up later — and the second undoes most of the point of the first. Storing a secret next to the thing it protects is not protection; it is a passphrase-shaped ritual. Martin's instruction was direct: *"I don't want a pass phrase to be saved or shown. The only thing that the user should need is their wallet.dat files."* ### How it works signature = wallet.signmessage(address, "DogecoinArcade messaging identity v1") seed = HKDF-SHA256(signature) identity = X25519 keypair from that seed `signmessage` is deterministic — RFC 6979 — so the same address always produces the same signature and therefore the same identity. Verified on Pepecoin: three calls, byte-identical. The address is filed in the wallet under the account `arcade-identity`. Accounts live inside wallet.dat, which is what makes a restore self-sufficient: the application finds the address again without needing its own database. ### The subtle part, which was a bug first `getaccountaddress` returns a **fresh** address as soon as the current one has been used. Calling it on each startup would therefore have changed the identity silently, orphaning every message already received — the exact failure the passphrase was removed to avoid. Caught in testing, before it shipped. The rule is now: take the account's existing addresses, sort them, use the first. `getaccountaddress` is reached only when the account is genuinely empty. Three independent installations against one wallet derive the same identity, and the CLI and the web interface agree with each other. ### What it costs, stated plainly **Whoever can use the wallet can re-derive the identity.** The wallet's security becomes the messaging security; if the wallet is unencrypted, so is the identity in practice. Against a standalone key with its own passphrase this is a real reduction, and it is the trade being made deliberately: the passphrase's failure mode was certain and common, this one requires an attacker to already have the wallet — at which point they have the coins too. A spending key is still never used for encryption. Deriving a separate X25519 key keeps encryption away from spending, so a compromise of one is not automatically a compromise of the other, and the messaging key can be rotated by moving to a different address without moving funds. ### Consequences - Fingerprints are gone from the interface. They named the identity in a form no user could act on. Names from the address book come first, then the address. The CLI keeps them: it is a diagnostic tool and that is where they belong. - `vault.py` — the credential store that remembered passphrases — is deleted. - Key files still work when named explicitly with `--key`, for identities made before this. They are never picked up implicitly, because the web interface derives from the wallet and the two halves of the application answering to different identities would be worse than either choice alone. - Backup and restore had to become real features rather than documentation: `arcade/backup.py` and the Backup page. If the wallet is the only thing that matters, keeping it has to be something a person can actually do. --- ## D-014 — Public group posts may run on mainnet (2026-09-11) **Decision.** A public, unencrypted group channel runs on **both** chains. D-010 is unchanged: nothing encrypted ever touches mainnet. ### Why this is not a reversal of D-010 D-010 says *the Messenger* is testnet-only, permanently, and the reasons were specific: messaging code is young, a bug in it must never be able to touch real value, and an encrypted message carries key material that would tie a mainnet identity to a correspondence. None of that applies to a public post. A group post is not sealed to anybody. It carries no key material. It reveals nothing that publishing it does not already reveal, because publishing it *is* the act. So the question "may this run on mainnet?" stops being a safety question and becomes a cost question, which is the user's to answer. Martin answered it. ### How the boundary is kept `MessageSender` still calls `require_messaging_network()` on construction. The only way past it is `public_only=True`, which is: - opt-in, never a default; - named for what it permits rather than what it disables, so a call site asking for mainnet has to say out loud that what it is sending is public; - passed by exactly one call path, the group-post route; - covered by a test asserting that encrypted sending is still refused on `main` and `doge-main`. ### Carriage, and why a post is short Class C: one OP_RETURN output. One output means **no dust**, so a post costs a fee and nothing else. That caps a post at about 60 characters. That is a real limit and the right trade. Class B would carry 7.5 KB, but it pays roughly one unspendable output per 30 bytes — on testnet that is free coins, and on mainnet it is somebody's money burnt to say something in public. A 60-character public post costs about 0.0028 in fees; the same text carried Class B would cost that plus several coins of dust forever. ### What the interface must say The rest of the application trains the expectation that messages are private, so the public half has to contradict that expectation loudly rather than quietly: 1. Every screen where a post can be written states that nothing there is encrypted, that it is permanent, and that it cannot be deleted. 2. The two chains are chosen explicitly, labelled *free coins, nothing at stake* and *real coins, permanent*. There is no single control that silently spends money. 3. A mainnet post shows the post's text back to the user inside the confirmation, with the fee, before anything is broadcast — the ground rule for mainnet transactions, applied here. ### Channels have no membership A channel is a name. Anyone using the same name is in the same room; there is no invitation, no member list, no way to remove anyone, and no moderation. Saying so plainly is the whole of the access-control design, and pretending otherwise would be worse than the limitation. --- ## D-015 — One starting block height per version (2026-09-11) **Decision.** Every installation reads messages from the same block, declared in code per network and changed only by a release. ### The problem it fixes Each machine began scanning at whatever height its own identity happened to be created. Two people running the same version therefore saw different histories, and neither could tell why: one would see a public post or a key announcement the other had simply never scanned. Nothing was broken, and nothing said anything — the machines were reading different parts of the same chain. That is a poor property for a shared medium. A public channel in particular is supposed to be the same room for everyone in it. ### How it works `Params.messaging_start_height` is a floor, applied first: floor = max(messaging_start_height, activation_height) start = max(recorded identity height, floor) A local record can push the start **later**, never earlier. Later is legitimate — nothing written before a key existed can be addressed to it, so reading it is wasted work. Earlier is not: it would let one machine read history the protocol says is not there. Testnet is set to **1,483,184**, the tip on 2026-09-11. Everything before it is development traffic from building the application, and is deliberately unread. ### What changing it means Raising it declares a clean slate for everyone at once. Lowering it asks every installation to rescan, which is cheap only if it is not lowered far. Either is a release decision and belongs in a commit, not in a setting — the value has to be the same everywhere or it is not doing its job. Clearing history locally ("Start fresh") resets to this height rather than to the machine's current block, so clearing brings an installation back into step with everyone else instead of pinning it wherever it happened to be. ### What it does not do It is not consensus. Nothing validates that a peer used the same value, and a modified client can read from anywhere it likes — the chain is public. It removes an accidental divergence between honest installations, which is what it was costing. --- ## D-016 — Tokens go live: the start block, and tokens on testnet for everyone (2026-09-12) **Decision.** The mainnet token index starts at block **1,208,000** (Pepecoin). Until the first token exists on mainnet the number may be moved by a release; after that it is fixed for ever. Tokens are **also indexed on testnet**, from 1,484,661, on every installation, and the Tokens page switches between the two chains by clicking the chain tag beside its heading. ### What "activation height" now means D-004 left it "set at launch, ~tip + 1 day", and M2 through M5 ran with mainnet set to `None`, which disables the index outright. The tokens interface is the launch: it creates, sends, grants and revokes on whichever chain is the ledger, and an index that never starts cannot show any of it. The value was chosen on 2026-09-12 at tip 1,206,546 — about a day ahead, as D-004 asked. It is still free to move. Nothing before the first mainnet token transaction depends on where reading began, so a later release may raise or lower it without changing what anyone holds. From the first token on, moving it would change history: raising it would un-create that token, lowering it could create another. So the rule is the one from D-015, sharpened: **changeable until it matters, then never.** Dogecoin mainnet stays at `None`. Nothing has been exercised there. ### Tokens on testnet, for everyone D-012 put the ledger on mainnet permanently. That stands: mainnet is where a token is worth anything. It does not mean testnet tokens are useless — they are how anyone tries the thing for nothing, and how the two machines check each other before real coin is involved. The alternative was trusting regtest alone: one node, no reorgs anyone did not stage, no second machine. So both chains are indexed, always, whether or not anyone is looking, and the Tokens page shows one at a time. Martin asked for exactly this shape: **the red "main" tag is the switch**. Clicking it goes to testnet, clicking the green "test" tag comes back, and the choice is kept in a file (`~/.dogecoinarcade/tokens-chain`) so an update does not put someone back on mainnet unasked. A token's own page carries its chain's tag but does not switch — the token belongs to that chain. The earlier `--ledger-network test` option, which made testnet the ledger for the whole process, is gone; one way to do a thing. Two consequences are worth writing down: - Testnet is read twice: once by the public-board scanner and once by its token index. Each keeps its own tip (`AppState.tips` and `AppState.ledger_tips`), because when they shared one the first reader hid every new block from the second. - The Messenger's transactions are all Omni type 200 (AnyData). Omni Core treats 200 as **valid and a no-op** (`tx.cpp:2735-2747`), and the engine now does the same. Before this, every message would have been indexed as an invalid token transaction with "not yet implemented", thousands of rows of noise about transactions that were never about tokens. This is a consensus-relevant change and it is free, because there is no mainnet ledger yet to disagree with. ### What is broadcast is what was shown Every token action is two submissions: the first builds, funds and signs a transaction and shows it decoded — sender, recipient, each output labelled, fee, total, txid; the second broadcasts. The second sends **the same bytes**. The prepared transaction is kept in the process under its txid and the confirm form hands that txid back; if it is no longer there (the server restarted), the action is rebuilt and shown again rather than sent. The wallet's plain coin send rebuilds on confirmation, which is harmless for a coin send with the same destination and amount but would let a token transaction go out with a txid and fee the user never saw. ### Sender and recipient are checked by the engine's own rules A token transaction the wallet funded is read back through `determine_sender` and `determine_reference` — the functions the indexer will run on it — and refused if they do not resolve to the intended addresses. Not a restatement of the rules in the builder: the same code. A send from the wrong address is a send of somebody else's tokens, invalid and paid for, and this is the check that stops it before the fee is spent. ### Where it stops An unknown or out-of-scope message type stops the index at that block (M2 hard rule 2, unchanged) and the tokens page says so, with the block and the type. Balances shown from then on are as of the block before. The index retries only when a new block arrives, since the block it stopped on will not read differently five seconds later. ## D-017 — A bot RPC in Omni Core's vocabulary (2026-09-12) **Decision.** arcade-web serves JSON-RPC at `/rpc/test` and `/rpc/main` with Omni Core's method names (`omni_getbalance`, `omni_getallbalancesforid`, `omni_send`, …), authenticated by a cookie file exactly as bitcoind is. Writing methods prepare and return the transaction; `omni_broadcast` sends it. Full reference: `bot-rpc.md`. ### Why Omni's names The engine is Omni's rules on Pepecoin; the people most likely to write a bot against it are the people who have written one against Omni Core. Giving them the names and field shapes they know (`propertyid`, `balance`/`reserved`/ `frozen`, amounts as strings) makes the port a URL change. Where the index holds no such thing — `reserved`, `frozen` — the field is present and zero rather than absent, so a client that reads it does not break. Where the arcade has something Omni does not, it is added (`omni_getinfo` reports the index's own height, what it is behind, and whether it stopped) rather than squeezed into an Omni field with a different meaning. ### Why a cookie, and why not the CSRF token The standing rule is cookie or `rpcauth` for the node, never a plaintext password in a script; the same reasoning holds one layer up. The server writes `~/.dogecoinarcade/rpc.cookie` (mode 0600, fresh each start) and a script sends it as HTTP basic auth. There is nothing to configure and nothing to paste. The forms' CSRF token is the wrong key for this: it is embedded in every page, so any script that can read a page has it, and a browser can be made to send it. The cookie lives only in a file the user owns, which a web page cannot read. Loopback binding stays what it was. ### Why sending is two calls Omni's `omni_send` broadcasts. Here it prepares, and `omni_broadcast` sends the bytes that were prepared — the same rule as the confirm screen (D-016). The alternative, one call that spends, was rejected because a bot that cannot see the fee before paying it cannot budget an airdrop, and because the transaction the server broadcasts should always be one somebody (or something) was shown. The cost is one extra call per send, which the example bot pays in one line. ### One URL per chain Omni Core serves the chain its node is on. The arcade indexes both, and the Tokens page has a switch. A bot must not follow that switch — a script that starts sending on mainnet because someone clicked a tag in a browser is a disaster — so the chain is in the URL and nowhere else. `/rpc` without a chain is a 404 that says so. The shell tool `arcade-rpc` defaults to testnet and needs `-main` said out loud. ### What it does not do No send-to-owners (Omni type 3). The engine does not implement it, and a transaction of that type stops the index (hard rule 2). Airdrops are one send per holder, which the example bot does with a done-file so a stopped run resumes without double paying. No rate limiting and no per-method permissions: the cookie is the operator's own authority, the same as the shell that can run `pepecoin-cli sendtoaddress`. ## D-018 — A door you can see, with a key and a deadline (2026-09-12) Reaching the wallet from a phone meant an SSH port-forward, which is fine for people who already know how and a wall for everyone else. The Remote page opens a Cloudflare quick tunnel and shows a QR code. The temptation is to call the random hostname the security. It is not: a URL is read over a shoulder, lives in a phone's history, and passes through Cloudflare's edge. So the tunnel is a route, and three separate things are the protection — a key that only the QR code carries, a deadline the user cannot forget to enforce, and a flat refusal to serve the bot RPC through it. Told apart by headers, not by address: cloudflared runs on the machine and connects to 127.0.0.1, so a phone in another country arrives from localhost. Verified against a live tunnel rather than assumed, and the guard deliberately does not treat an unfamiliar Host as remote, so someone reaching their own wallet over their own LAN is not locked out by a feature they never enabled. Registered as middleware, not per route. A door guarded route by route is a door that is open the first time somebody adds a route and forgets. cloudflared is pinned by version and by hash. Cloudflare publishes no checksum file beside the binaries, so the hashes come from GitHub's asset digests, read once and written into the installer: it checks against something it carried with it, not against a number fetched from the same place as the file. ## D-019 — Collections are read from the chain, and a run is a file on disk (2026-09-14) A HashLips build is a few thousand pictures with a JSON file each. Inscribing one by hand is a few thousand trips through the single-file form, so there is a wizard: point it at the `build` folder, see every item priced, confirm once. Two decisions underneath it. **The collection is what the JSON says, not what the wizard was told.** The wizard could have written "these belong together" somewhere — a manifest inscription, a field of its own. It does not. The index files an inscription into a set from its inscribed JSON alone: `collection` if there is one, otherwise a `name` ending in `#`, which is the shape HashLips already writes. Every node running the indexer files the same sets from the same bytes, nothing has to be inscribed in addition to the items, and a set cannot be renamed or hijacked afterwards because there is nothing to edit. A set is keyed by its creator as well as its name, so two people using the same name are two sets. The ledger schema is version-locked, so the filing lives in a new table of its own, filled in for an existing index the first time it is opened. **A run is a job on disk, written one transaction at a time.** Every txid the node accepts is recorded before the next piece is built. Pause is a flag read between pieces; resume starts at the next piece with no txid; a crash is a `running` job found at startup, which restarts itself. The one gap — the node took a transaction and the machine died before the record was written — is closed by asking the chain index which pieces of that inscription id it has already seen, so the worst case of a power cut is nothing, not a duplicate paid for twice. The wallet is split in batches sized by the largest item coming up, so a long run neither waits a block per piece nor makes ten thousand outputs at once, and the send lock is held per item so messages still go out during a run. ## D-020 — A caller may ask; only the person may send (2026-09-14) An inscribed page and a bot on the RPC both have reasons to want this wallet to move something — a marketplace, a game, a prize. Neither can be allowed to do it. A page is code a stranger inscribed, running in a frame of a wallet that can spend; a bot with the cookie can already spend, but a bot that a stranger's code can drive should not be handed that. So there is one more verb between "read" and "send": **ask**. `POST /r/send` and `da_request*` file a request — kind, recipient, amount, and the caller's own words about itself and why. The request is a row on disk, not a transaction: nothing is built until the owner looks at it, and what is built then is shown in full and broadcast only if the yes names the txid that was shown, the same rule as every other send (D-016). It is one queue for coins, tokens and inscriptions because the person deciding should see one screen whatever is moving, and the caller should learn one shape. Two limits keep asking from being a nuisance rather than a risk. A request nobody answers within an hour expires, so a page somebody looked at last week is not still asking. No more than twenty may wait, so a page that files in a loop gets an error, not an audience. Filing needs no key at all — the frame has no origin to present one from — which is fine precisely because filing is a question. The `omni_send*` calls keep their two-step for a program that holds the wallet; the difference between them and `da_request*` is whose finger is on the button. ## D-021 — The wallet remembers for a page; the page never gets an origin (2026-09-14) "Can inscriptions use localStorage? They should be able to." They should, and they cannot: a sandboxed frame without `allow-same-origin` has an opaque origin, and an opaque origin has no storage — the browser throws on the property itself. The flag that would fix it is the flag that would hand a stranger's code this wallet's origin, cookies, CSRF token and every page in it (D-018). A second origin for content would work on this machine and not over the tunnel, where there is one hostname, and it would still put every inscription in one shared bucket. So the wallet remembers instead. The page loads `/r/storage.js` and gets `arcade.storage`, the shape of `localStorage` with a `ready` promise in front of it; the shim talks to the viewer over `postMessage`; the viewer — the wallet's own page, outside the sandbox — keeps the data in `~/.dogecoinarcade/pagedata.sqlite` under the id of the inscription in the frame the message came from. The page never says who it is, so it cannot lie about it. Limits (256-character keys, 64 KiB values, 1,000 keys and 1 MiB per page) are there so a page in a loop fills its own room and nothing else. Two things fall out that `localStorage` would not have given. The data is the same on the phone and the desk, because it is the wallet's and not the browser's. And the same channel is why the approval pop-up is safe: it is a frame of the wallet's own page held by the viewer, `frame-ancestors 'self'` on every page the wallet draws, and the inscription can neither see it nor frame one of its own. ## D-022 — Over the tunnel, inscribed pages get a hostname of their own (2026-09-14) Testing everything on testnet over the real tunnel found the inscribed shop page saying "…" on the phone. Every `fetch('/r/…')` from inside the frame came back 403: the sandbox gives the page an opaque origin, and a document with an opaque origin sends no cookie — not the remote key, nothing. Its own `