01
Start here
Build a Metanet application
Keep keys out of app code, ask a standards-compatible wallet to act, and make permissions legible to users.
OutcomeA portable app that can work across BRC-100 wallet implementations.
Outcome-first architecture
Start with the job.
Compose the right BRCs.
Each path is an editorial implementation sequence. It narrows the catalog to a coherent stack without pretending that a BRC number, package, or vendor is the whole system.
02
People and peers
Add identity and private communication
Derive relationship-specific keys, reveal only needed certificate fields, and authenticate both ends of a channel.
OutcomePrivate, mutually authenticated interactions without app-held master keys.
03
Shared application state
Run an overlay service
Admit only protocol-valid transactions, expose focused lookups, discover peers, and keep topic state synchronized.
OutcomeA scalable, independently operated view of application-specific on-chain state.
04
Value exchange
Send and receive peer payments
Compose derivation data, proof-carrying transactions, wallet receipt, and HTTP payment negotiation.
OutcomePayments that remain portable across wallets, transports, and service vendors.
05
SPV foundation
Exchange proof-carrying transactions
Choose current transaction and Merkle-proof containers, then scope them to a transaction or output.
OutcomePortable validation packages without a dependency on one provider’s database.
06
Digital assets
Support 1Sat assets in a BRC-100 wallet
Track wallet-owned token outputs, origin provenance, inscription envelopes, and portable proof packages.
Outcome1Sat asset flows that fit the same wallet and proof architecture as the rest of the Metanet stack.
01
Normative source
The BRC text defines the protocol. A path never silently changes it.
02
Editorial sequence
Ordering reflects implementation dependencies and can evolve as the ecosystem does.
03
Vendor neutral
Reference software proves feasibility; the interface remains the point of interoperability.