A Sovereign Economic Community (aka a Rocket) is a coordination layer that harmonises Sovereign Human Action for fun and profit.
The history of an SEC is stored using a Microsubjective Blockchain as described in NIP 31108. This specification describes the Ruleset that an MSB adopts to host an SEC.
todo: NIP1409 (sale of merits); 1602/1603 (merit requests and votes); NIP1908 (products); NIP886 (Sybil Trees), NIP1971 (Problem tracking).
This MSBR requires >80% of the SEC's votepower to add/remove ruleset identifiers and >60% to increment a ruleset identifier to the next stable version.
A problem SHOULD be included by the creator of the SEC in their ignition event.
[ "problem", 31971:<problem creator pubkey>:<kind 31971 problem tracker event d tag>, <relay hint> ]
The problem statement MAY be altered by >80% of the SEC's votepower.
[ "mission", <string, less than 140 characters> ]
The mission statement MAY be altered by >80% of the SEC's votepower.
Problem: how to get the news off an Internet with far too many interesting sources of information.
Mission: the front page of the Internet.
At minimum ONE repository SHOULD be included by the project creator in their ignition event.
[ "repo", 30617:<repo publisher pubkey>:<NIP34 repo announcement d tag>, <relay hint> ]
Repositories MAY be altered by >80% of the SEC's votepower.
Product listings index
[ "product", <product event id>:<price (millisats)>:<start time (unix)>:<max number of purchases>, <relay hint>, <JSON stringified purchases> ]
Payments tracking for products, embedded as stringified JSON array in the "product"
["<zap receipt ID>:<buyer pubkey>:<witnessed at block height>", ...]
Updates to product payments SHOULD be accompanied by a proof (stringified zap receipt).
Products MAY be altered by >80% of the SEC's votepower.
Merits are the canonical representation of equity within a SEC. Upon approval of a new Merit Request, or a transfer or sale of an approved merit request (see NIP 1409), a tag entry is created or modified.
[ "merit", "<owner pubkey>:<event ID of approved merit request>:<current leadtime>:<last leadtime update>:<number of merits>" ]
Updates to merits SHOULD be accompanied by a proof of either:
- a stringified merit request kind
1602and stringified votes of kind1603 - a Bitcoin TXID in the case of the sale of an approved merit request (see NIP 1409)
Instead of tracking satflow based on each pubkey (an accounts paradigm), we do it using approved merit requests (something akin to the UTXO model). This allows merits to be transacted without losing their satflow history.
For each approved merit request:
[ "sats", "<merit request ID>:<amount outstanding>:<amount paid>" ]
Decrements to the amount outstanding SHOULD be accompanied by a proof (stringified zap receipt and the recipients current kind 0 event with the zapper pubkey).
We keep this in a separate tag rather than embedding it in the merits tag so that they can be independently modified.
Some merit holders in a SEC may have votepower. Votepower is how we quantify a Participant's skin in the game.
Votepower = Merits * Leadtime
- Every Approved Merit Request's
Leadtimestarts at0. - An Approved Merit Request cannot be spent/transferred/sold if its
Leadtime > 0. - A Participant MAY increment or decrement the Leadtime on an Approved Merit Request owned by them ONCE every 2,016 blocks (but can't become negative)
Participants who hold merits with a votepower >0 SHOULD publish kind 31108 state events which allow consumers of these events to verify that there is consensus over the current state. They may also simply shadow someone else who also has votepower.
To validate if consensus has been reached over a given state, Participants fetch all the latest state events from each pubkey that has votepower >0 in their last known state (or just start with the ignition event). This section will be updated with further details once fully implemented.
If 100% of the current votepower is in agreement over the current state, we don't need to validate any proofs other than that required to validate the current set of pubkeys holding votepower.
Approved Merit Request can be listed for sale by the current owner.
["amr_sale", <merit request ID:start price:end price:start height:rx address>] ${request.RxAddress}:${0}:${request.StartPrice}:${request.EndPrice}:${request.Merits}:${requestIDs}
A stringified kind 1412 proof is required to add to this state (see MSBR3340.merits).
The price begins at the starting price and reduces every block till it reaches the end price when the auction closes without a sale.
When we see a confirmed UTXO spendable by rx address and it is >= the current price as described above, we check the "address" tags in our current state and look for a corrosponding npub. We include the UTXO string as a proof and update the corrosponding merit tag for this merit request ID.
Clients should check mempool for UTXOs to avoid users buying a merit request that already has a UTXO in mempool.
To purchase Approved Merit Requests from contributors, a buyer MUST prestate which address their payment will come from. This is how we know which payment is associated with which nostr pubkey.
Change addresses do not need to be re-added, clients should follow UTXOs to get these.
["address", <pubkey:bitcoin address>]
Additions to this state MUST be accompanied by a proof, either a kind 1413 address addition event, or the hex string of a Bitcoin transaction.
The creator of an SEC may enable funding to come from other SEC's. This means that one SEC owns part of another SEC (and also recieves a proportion of the revenue).
["crossfunding", "true"]
This enables the owner of an Approved Merit Request (MSBR3340.Merits) to access a larger market of funding if they wish to sell their AMR for sats.
An SEC has three options for handling the distribution of incoming payments (for products/services created by the SEC).
When someone wants to purchase a product/service from an SEC, they are provided with an invoice from the next pubkey in a round robin derived from ratio between how many merits each pubkey holds and how many sats they have recieved for the life of the SEC. The distribution of incoming payments is eventually-consistent with the distribution of merits.
This is a totally non-custodial way to operate an SEC.
The creator of an SEC can spin up a Cashu mint on top of any funding source, with a dedicated LUD16 address for each product/service.
When receving an incoming payment, their mint DMs each merit holder with the correct proportion of tokens based on their proportion of merits.
Merit holders can request a withdrawal at any time.
This can also be a service provided by another SEC.
The simplest way to handle incoming payments is for the creator of an SEC to create a new LUD16 for incoming payments and provide a pubkey for valid zap receipts. When a zap receipt is published, the kind 31108 event is updated to reflect the new outstanding amount owed to each merit holder. Upon withdrawal request, the SEC creator SHOULD zap the merit holder and update his 31108 event to reflect the new state.
We currently use zap reciepts as proof of payment.
The rocket MUST have at least one LUD16 address specified for incoming payments, as well as a pubkey for valid zap reciepts. In the case of the round-robin, each merit holder to be included in the round-robin MUST have a LUD16 and pubkey for zap receipts specified.
The zap request MUST include the product ID.