Build the Lane Lite phone node.

A Lite node is a pure transport relay. It opens an outbound WebSocket to the coordinator, receives a Solana transaction that is already signed, submits it to an RPC, and reports back the signature. The node never builds or changes a transaction (ADR-006), so it holds no funds and carries almost no trust: the worst a coordinator can do is withhold a job.

Outbound-only is deliberate. Phones sit behind carrier NAT and have no public IP, so the node dials out to the coordinator rather than the other way around.

How the node earns

• Instant USDC — 0.375% of every transaction it relays, paid on-chain straight to the node's own wallet at settlement. The fee destination is fixed on-chain, so it cannot be redirected.
• SINKY accrual — 0.015/day × active-factor, where active-factor = min(session_hours, 12) / 12. Paid out in weekly batches.

Before a node can go online, its wallet must be a registered, active Lite node.

• A Solana wallet (keypair) on the device.
• Stake 25 SINKY once via the program's register_node instruction, which maps the wallet to the Lite tier on-chain. For the MVP this can be done on the website /depin/setup or the CLI, so the app does not need to build the stake transaction on day one.

Devnet parameters

This is the contract, one JSON object per text frame. It is identical to the reference Node.js runner already relaying on devnet, so the Android app can port it 1:1.

1. server → sends a one-time challenge with a random nonce.
2. client → ed25519-signs "solinkify-lite-v1:" + nonce and returns auth with the wallet pubkey and base58 signature.
3. server → checks the signature and the on-chain node, then sends ready (or denied with a reason).
4. server → pushes a job: a job_id and a base64 already-signed transaction.
5. client → submits the tx to the RPC, then replies result with the signature (or error with a message).

// 1. server → client
{"type":"challenge", "nonce":"<uuid>"}

// 2. client → server   (sig = base58 of ed25519 over the UTF-8 bytes below)
{"type":"auth", "wallet":"<base58 pubkey>",
 "signature":"<base58 ed25519( 'solinkify-lite-v1:' + nonce )>"}

// 3. server → client
{"type":"ready"}
{"type":"denied", "reason":"wallet is not an active Lite node (register 25 SINKY first)"}

// 4. server → client
{"type":"job", "job_id":"<id>", "tx":"<base64 signed tx>"}

// 5. client → server
{"type":"result", "job_id":"<id>", "signature":"<sig>"}
{"type":"error",  "job_id":"<id>", "message":"<err>"}

These match the coordinator, keep them exact.

• Auth window: send the auth frame within 15s of the challenge.
• Relay window: the coordinator waits 8s for your result/error per job, then falls back to another route.
• Heartbeat: written by the coordinator every 5 min while you are connected. The node does not send heartbeats.
• Daily session cap: 12h/day UTC. Beyond that, accrual does not grow, so disconnect until 00:00 UTC to save battery.
• Reconnect: backoff starting ~2s, doubling, capped at 60s.

• Key management on-device — import a keypair (base58, e.g. a Phantom export, or a JSON array), stored in Android Keystore / EncryptedSharedPreferences. Never plaintext.
• ed25519 signing — sign the auth string with the wallet key (libsodium, Tink, or a Solana-Kotlin library).
• WebSocket client — OkHttp or Ktor, with reconnect + backoff and ping/pong.
• RPC submit — POST sendTransaction (base64) and parse the signature. Only later, in-app staking would need richer Solana tooling.
• Foreground service — a persistent socket needs a foreground service with a notification; Android kills background sockets.
• Status UI — live session time (x/12h), estimated SINKY accrual, and a jobs-relayed counter.

Most of the runner is light. The two real challenges are Android platform behavior, not the protocol:

• Keeping the socket alive. A foreground service with an ongoing notification is required, plus handling Doze mode and battery-optimization exemptions so the OS does not suspend the connection.
• Key safety. The private key controls real funds. Store it encrypted (Keystore-backed), never in plaintext or logs.

A build path in four phases. Phase 3 is the proof: a real payment relayed by the phone, verifiable on-chain. (Ticks are a reading aid and do not save.)