London 0.1.0

APPROVED · IMPLEMENTATION SPECIFICATION · London 0.1.0

Approved direction: Move accounting, one streaming-node role

The product owner has approved simplifying London to a player, small coordinator, private S3 audio origin, streaming nodes and Move-owned accounting/payout state. Any eligible artist or other participant can operate the same streaming-node software. A real node-to-node cache transfer remains part of the pilot.

The authoritative accounting and payout contract is Move-owned accounting and payout protocol. It supersedes the preceding RocksDB-first priority and hash-only commitment contract. Where an older chapter conflicts with this protocol, the Move protocol prevails. Do not build the old local financial ledger or commitment-only settlement path.

Start with the Move storage spike: Table and BigOrderedMap candidates, bounded accounting, Mainnet limits, local collection tests and explicit remaining benchmark gates. Collection selection is a research recommendation, not a production-scale result. The next specification revision must align accounting, privacy, USDC transfers, APIs and acceptance tests before implementation.

London still excludes PRT, a custom chain and an independent attestor network. Approval of the direction is not deployment, security clearance or observed real payouts.

Previous specification, pending revision

The chapter structure below is retained for the coordinated rewrite. Its earlier approval and validation records describe the previous specification, not completed validation of the revised architecture.

Read by responsibility

Reader	Start here	Then implement against
Product / human overview	Scope, executive architecture, journeys, pilot	Launch inputs and measured success boundaries
Backend	Architecture, streaming, accounting, data model	API, artifact schemas, fixtures and acceptance cases
Node / infrastructure	Streaming, node package, security, operations	Peer authorisation, durability and failure tests
Frontend	Journeys and human-facing states	OpenAPI and browser acceptance matrix
Move / verifier	Commitment module and wire formats	Golden fixtures, append invariants and proof verdicts
Finance / legal / security	Funding, rights, trust and required launch inputs	Production profile and G5 sign-offs
Any implementing agent	Implementation plan and scope exclusions	W0-W7 and A01-A48 traceability

Complete specification

• Build first: deterministic RocksDB ledger

• Status, approval and exact scope

• Executive architecture

• System architecture and ownership

• Roles and trust model

• Listener, artist and operator journeys

• Catalogue, rights and content

• Playback, peer delivery and usage evidence

• Basic integrity controls and manual exceptions

• Funding, accounting and real payouts

• Move-owned accounting and payout protocol

• Backend modules, APIs and provider boundaries

• Data model, state machines and ledger

• Security, privacy and key management

• Operations, recovery and incidents

• Testing, proof levels and launch gates

• Future compatibility, no migration implementation

• Implementation plan and agent handoff

• Required launch inputs and residual risks

• Compatibility with existing Porto sources

• Architecture decision records

• API contracts and endpoint catalogue

• Canonical wire formats, artifacts and verification

• Acceptance test catalogue

• Source register and authority

• Validation and impact report

• Node package and participation pilot

• Configuration and release profile

• Glossary

Machine-readable handoff

• Ledger schemas: command envelope, journal and portable checkpoint.
• Ledger fixtures: canonical hashes and journal chaining examples.
• OpenAPI: complete coordinator/node HTTP surface and schemas.
• Artifact schemas: evidence, accounting, statements, indexes, payment journals and corrections.
• Release profile schema: mandatory production inputs, no invented commercial defaults.
• Fixtures: synthetic canonical hash and allocation vectors.
• Source manifest: pinned canonical source evidence.

Canonical source directory is porto/docs/london-0.1.0/. The existing Docusaurus build reads it directly and publishes this section under /london-0.1.0/overview. Documentation and schema validation do not establish application security, Mainnet deployment or successful pilot results.