WHITEPAPER — DEFENSIVE PUBLICATION DRAFT

SARDENE: A Protocol for Direct Compute Donation

Sovereign Autonomous Research & Distributed Edge Network Engine

Abstract. SARDENE is an open, serverless protocol that lets anyone donate computing resources — cryptocurrency mining cycles or real computational work — directly to a person, project, or model-serving swarm of their choosing, with no platform, account, or fee extractor in the middle. Identity is a keypair. Routing is peer-to-peer. Contribution is measured by signed receipts and a local credit ledger, and access to shared resources is gated on contribution ("contribute-to-use"). The protocol is tiered so that anything from a Raspberry Pi or phone to a multi-GPU rig can participate at its capacity.

This document is a defensive publication. It is published to establish prior art over the designs described herein as of the date above.

1Design principles

1. Protocol, not platform. SARDENE is a set of formats and behaviors any implementation can speak — the SMTP/Gmail pattern. Platforms may be built on top, but the protocol itself belongs to nobody and its security does not depend on any organization continuing to exist.
2. No central server. Peer discovery is via signed LAN multicast beacons and bootstrap peer lists; wider-area routing uses existing P2P substrate (DHT/Nostr-style relays). There is no server to seize, subpoena, or shut down.
3. Direct flow of value. Mining proceeds go from pool to the recipient's wallet address directly. Compute results go from donor to creator directly. The protocol never custodies funds or work product.
4. Contribute-to-use. Shared resources (model-serving swarms) are drawn only by nodes that contribute to them, enforced by a signed credit ledger. This prevents leeching and prevents low-capacity nodes from burning high-capacity capacity they don't help provide.

2Identity

Each node is an Ed25519 keypair generated locally (identity.py). There are no accounts, emails, or registrations. Every receipt, beacon, and result is signed; verification is offline. A node's track record is the accumulated signed receipts attached to its public key — verifiable by any peer, not stored or adjudicated centrally.

3Capability profiles

One protocol, three builds — the same wire format at every tier:

The active profile is announced in signed peer beacons, so the network can report its composition (e.g. "this swarm is served by 40 sardines, 3 dolphins, 200 anchovis").

4Capacity cohorts and per-model swarms

Each node probes its hardware (CPU threads, RAM, GPU VRAM — capacity.py) and is classified into a cohort (edge / consumer / prosumer / workstation). Model swarms are per-model: a node joins the swarm for the largest model it can hold a slice of (models.py):

• Full-local: small models (≤ ~9B quantized) served entirely on one node.
• Block-host: contiguous transformer blocks of a larger dense model (pipeline parallelism, Petals-style).
• Expert-host: individual mixture-of-experts experts of large sparse models (e.g. DeepSeek-class MoE), where only ~5–10% of parameters activate per token — the configuration that makes very large models servable over WAN-grade links.

A large node joins whatever swarm currently needs its capacity; swarms re-form dynamically as nodes join and leave (churn is expected and handled by DHT-based re-routing, not prevented).

5The cruncher

One-click mining donation (cruncher.py): the user types any Monero wallet address and a CPU percentage; the node mines via a pool that pays that address directly (p2pool by default). The miner process is CPU-capped and runs at idle priority. RandomX is deliberately chosen: it is the only major proof-of-work where CPUs — including phones — are not a rounding error relative to GPUs/ASICs. The reference implementation does not auto-download miner binaries; the user supplies and verifies the binary.

6Task donation

Creator-defined compute jobs (jobs.py): a job manifest packages a task into independent shards. Donor nodes pull shards, execute them in resource-limited subprocesses (rlimits on CPU/memory/time), and return results signed with their node identity. Quorum verification: a shard result is accepted only when two independent nodes return identical output hashes; single-submission results are marked disputed. Verification cost is bounded redundancy (~5–10% of network capacity). Roadmap: WASM/WASI sandboxing for stronger isolation, and cryptographic proof of inference when it becomes economical.

7Credits and contribute-to-use

Every verified contribution (shares mined, shards crunched, model blocks or experts served) issues a signed credit entry in a local append-only ledger (credits.py). Drawing on a swarm requires sufficient credits earned contributing to that resource class. This is the BitTorrent-ratio principle applied to compute: it is the anti-freeloader and anti-throttling mechanism, and it requires no global consensus — credits are verifiable receipts, not a currency.

8Threat model (honest version)

• Malicious results — mitigated by quorum redundancy and reputation; roadmap: sampled re-execution and ZK proofs.
• Malicious job code — rlimits are a soft sandbox, not a hard one; roadmap: WASM. Until then, task donation is opt-in: a donor node accepts job manifests only from addresses the donor explicitly chooses.
• Antivirus misclassification — any mining tool is flagged by AV vendors. Mitigation is transparency: user-supplied binaries, checksum verification, no bundling.
• Mobile distribution — app stores ban on-device miners; phone-tier nodes are expected to favor task donation, and mining builds ship via F-Droid/sideload only.
• Physics — WAN latency bounds interactive sharded inference to chat-grade (a few tokens/sec) responsiveness; training across the WAN requires communication-infrequent methods (DiLoCo family). Bandwidth scaling eases the training case over time; latency does not scale.

9Prior art and intellectual property statement

This document, together with the reference implementation, constitutes a defensive publication establishing prior art as of 2026-08-03 for the designs described herein, including: per-model capacity-tiered donation swarms; contribute-to-use credit gating over donated compute; the anchovi/sardine/dolphin capability-tier ladder over a single protocol; direct-address mining donation routing; and quorum-verified volunteer task donation.

The reference implementation is licensed AGPL-3.0-only: the protocol is free for anyone to implement and use, and any networked deployment of a modified implementation must publish its source. This specification document is licensed CC-BY-4.0 so that it may be freely cited, mirrored, and archived as prior art.

The names SARDENE™, anchovi, dolphin, and Start Ink are in use as marks identifying this project and its tiers as of the date above. (The protocol's wire identifiers — the sardine:address meta name, /.well-known/sardine.json, and the sardine capability tier — keep their original spellings as technical constants.)

10Roadmap

1. Cruncher fleet acquisition (the wedge; everything recruits from it).
2. Live sharded inference swarms via the Petals adapter (serve.py).
3. WASM-sandboxed job execution.
4. Federated training track (DiLoCo-style infrequent sync).
5. Cryptographic verification of contributed inference.

11Recipient discovery convention (ADDED 2026-08-07)

Direct donation needs a way for a creator to say "here is my address" that a donor's software can pick up without an intermediary. SARDENE standardizes four levels of self-declaration, from invisible to visible:

Invisible — page metadata. A creator embeds their address in the HTML head of any page they control:

<meta name="sardine:address" content="XMR address">
<meta name="sardine:label" content="...">   <!-- optional -->

Machine-readable — well-known document. A site publishes /.well-known/sardine.json:

{"sardine": 1, "address": "...", "label": "..."}

Visible — a plain link. A creator adds an ordinary anchor anywhere on the page:

<a href="https://example.com/your-page">donate compute</a>

Without the browser extension installed, the link lands on the creator's own page. With the extension installed, the same page offers one-click "save to phonebook" and "start donating" — both explicitly confirmed by the user, never automatic.

Installer-carry — one-click install for new donors. A creator links directly to the reference download gateway with their address in the query string:

https://sardene.com/download.html?address=...&label=...&preset=light

The gateway downloads both the platform installer and a small sardene-referral.json starter file. The installer carries the starter into the donor's state directory, so the first-run wizard pre-fills the creator's wallet address and pre-selects the suggested CPU preset. The address comes from the referral file the creator generated; Sardene has no knowledge of its contents and does not verify the address. The donor confirms before any donation begins; the starter file is single-use and never alters the creator's own page.

Deep-link — open an installed app. For donors who already have Sardene, a sardene://add?... link opens the app and asks to add the wallet:

sardene://add?address=...&label=...&preset=light

The action may be start or add; both are equivalent, and both require donor confirmation before anything runs.

Security model. Discovery is self-declaration: there is no registry, because a curated registry is a capture point — whoever controls the list controls the money. The browser extension is a dumb pipe: it reads these declarations and POSTs them to the user's own loopback dashboard, authenticated by a per-install token that websites cannot forge. Saving an address to the phonebook never starts donating; activation into the active recipient set is a separate, deliberate act by the user.

No central directory. The reference implementation does not ship a curated registry. A registry is a chokepoint — whoever controls the list controls the money. The protocol relies on self-declaration only. Anyone can publish an address; anyone can point a miner at it. The reference implementation ships with no pre-configured addresses.

12Adjacency policy (ADDED 2026-08-28)

Sardene is the rail, not the mall. The core project publishes open-source software that lets people donate computing resources directly to a wallet address they choose. It does not run a directory, hold wallets, take a cut, vet recipients, moderate users, or intermediate funds.

Adjacent businesses and extensions are welcome, but they must live as separate projects: a curated cause directory, a fiat cash-out service, a creator portal, a marketplace, a token layer, an exchange, a fork for a specific use case — all of these can be built around Sardene, but not inside it. They may be linked from Sardene documentation neutrally if they are useful and clean. Sardene does not partner-exclusively, endorse, or take a cut of any adjacent project.

This boundary exists because platforms become capture points. A curated registry can be pressured, a custodial wallet can be seized, a marketplace can be regulated, and a token layer can be manipulated. Keeping Sardene as a bare protocol and reference implementation removes those levers. The protocol survives any organization; the reference code can be forked; the donation path does not depend on this domain continuing to exist.

13Wallet safety and operational notes (ADDED 2026-08-28)

Sardene's discovery convention requires only a public Monero address — the 95-character standard address or 106-character integrated address that starts with 4 or 8. This address is intended to be shared. Creators publish it on pages they control; donors paste it into the app.

The following must never be shared with any website, donor, or third party:

• The wallet's seed phrase (typically 24 or 25 words).
• The private spend key.
• The private view key.

These values control the funds. Sardene never asks for them, and no legitimate donor or service needs them to send mining proceeds to a public address. A creator who is asked to provide seed or keys to "activate" donations is being targeted by a scam.

Creators are responsible for their own wallet hygiene: use reputable wallet software, keep backups offline, and verify any exchange or broker independently before sending funds. Sardene does not custody, recover, or reverse transactions.