Specification, draft v0.1 John McManus, August 2026 ordain.art/protocol
Ordain is a protocol for commissioning creative work, settled in bitcoin over Lightning. A patron describes a work they want made and puts money behind it. Other patrons may add to the commission. Creators anywhere compete to make it. At settlement, the patron awards half the payment at their discretion; the creators who submitted divide the other half by peer vote. A commission unfulfilled at its deadline stands open until settlement, withdrawal, or its final close. No party custodies the funds at any stage, and no party can prevent a payment, alter a tally, or bar anyone from submitting. The mechanism that binds a pledge without custody is not yet built. Participants hold keys, and nothing about a key says whether a person or a program holds it. Whoever answers a commission may post further commissions for its parts.
Ordain runs today as a hand-coordinated commission board at ordain.art; this document specifies the protocol.
The big patronage platforms run in one direction only, creators proposing and crowds funding; the freelance marketplaces let a patron hire, but they custody the payment, keep the register of accounts, take a cut, can remove either party at will, and are closed to anyone they cannot bank. Nowhere can a patron post a want in public, bind money to it, and let anyone on earth answer with no company in between. And whatever a creator earns is priced in their local currency, against their local wage floor: the same work at the same standard pays a filmmaker in Lagos a fraction of what it pays one in Los Angeles.
Bitcoin removed the intermediary from money. This protocol proposes to remove it from commissioning.
Commission. A public offer to pay for a work that does not yet exist: a brief, settlement terms, and the identity (real or pseudonymous) of the commissioner. The settlement terms, all declared at posting: the payment amount, a deadline, a field threshold, a settlement window, a voting window, an award window, a final close, the ballot form (2.4), a minimum payout (2.4), and, for indivisible work, an on-spec threshold (2.8).
Commissioner. The patron who posts a commission. A commission has exactly one commissioner, regardless of how many patrons fund it.
Pledge. A public promise of funds toward a commission. The commissioner’s initial amount is the first pledge; additional patrons may pledge to the same commission. Pledged funds remain in the pledger’s possession until settlement.
Creator. Anyone who submits a work in answer to a commission. Submitting requires no qualification, registration, or permission.
Submission. A work, or a verifiable reference to a work, offered by a creator in answer to a commission before its close.
Vote. A creator’s scoring of the other submissions to a commission. A creator never scores their own work.
Tally. The computation that converts all votes into each creator’s share of the peer pool, deterministic over a fixed set of vote events; 3.2 fixes the set.
Settlement. The set of Lightning payments that close a commission, in the proportions the commissioner’s award and the tally dictate (2.5).
Standing commission. A commission past its deadline that has not settled. It remains open, at its full amount, until it settles or reaches its final close.
Settlement window. A declared period, opened by the rules in 2.3, during which the field takes final shape before the settlement question is put.
Occasion. One putting of the settlement question: the field fixes, the voting window runs, and the commissioner settles or rolls (2.3). An empty field never generates one.
Roll. A commissioner’s answer, express or by silence, that a commission remains standing.
Final close. A date, declared at posting, on which a commission’s settlement question is put for the last time.
Coordination layer. Everything the protocol needs short of binding money: commissions, pledges, submissions, votes, the tally, and the public record of settlement. Buildable today.
Commitment layer. The unbuilt mechanism that makes a pledge unpullable without custody (2.1; Section 4). Until it exists, pledges bind socially rather than cryptographically. Properties that wait on it are marked [commitment layer].
An open protocol on which anyone, anywhere, runs a commissioning board with no operator. A commission, its pledges, every submission, every vote, and every settlement record are signed public events, verifiable by any stranger reading the record the commission names (3.2).
Nothing in the protocol caps participation: one pledge or a million, three submissions or a hundred thousand.
A pledge binds from posting, exitable before the first submission only by notice (2.3); from the first submission it holds until settlement or the final close, custodied by no one, paying out automatically to winners unknown when the money committed. [commitment layer]
Settlement pays every creator their share from every pledger at once (2.5). [commitment layer; the coordination layer supports multi-patron pledges and client-assisted settlement today]
Identity on all sides may be pseudonymous: nothing in the protocol requires a legal name. Votes are public and signed, which makes the tally verifiable and a voter’s rankings permanent; sealing ballots while keeping the tally verifiable is an open problem (PROBLEMS.md).
No party can alter a tally computed over the record the commission names. The protocol survives the seizure of any participant, including the reference client at ordain.art; any community holding the specification and the record can continue or replicate any commission.
Every commission divides into two equal pools.
The commissioner awards one pool at their sole discretion: all to one creator or divided among several. The award is declared after the vote closes, so peer judgment informs it and never binds it, and it must arrive within the award window (2.3). Enforcing settlement against a silent pledger is a commitment-layer property. [commitment layer]
The creators who submitted divide the other pool by the ballot of 2.4. A creator’s vote has no effect on their own payout. The tally assigns a peer-pool share only to creators who voted in the settling occasion’s window (2.4); shares that would have gone to non-voters redistribute proportionally among those who voted. Forfeiture reaches only the peer half: a creator who did not vote remains fully eligible for the award, and a creator with no one to rank owes no ballot, so a field of one forfeits nothing.
A commissioner-only award invites patron capture and race-to-the-bottom pricing. A creator-only vote invites collusion.
The reference client’s defaults are a threshold of three submissions, a thirty-day settlement window, and a final close one year from posting; the protocol fixes none of the numbers in a commission’s settlement terms (Section 1), only that they be declared. A default threshold of three is the smallest field where a vote says anything; boards expecting collusion should declare higher (Section 4, the small field).
Settle or roll is the only decision a commissioner makes between pledging and paying, and the question arises on exactly three kinds of occasion. At the deadline, over whatever field exists; an empty field converts without asking. After the deadline: an unsettled commission converts to a standing commission, whose settlement window opens automatically, each new submission at or past the threshold opening one, with later submissions joining the field rather than opening windows of their own, or voluntarily, the commissioner declaring a window open at any time over a field of at least one, outside any running occasion. And at the final close, over whatever field exists, for the last time. Each occasion runs one sequence: the field fixes when the occasion closes, the voting window runs (2.4), and the commissioner answers within the award window, a closing event to settle (3.1) or silence to roll; a prevailing no-award on the ballot (2.4) rolls the occasion regardless of the answer.
After a roll the commission stands, every submission and every vote stays on the record, and the question returns with the next new submission or the commissioner’s own window event. Silence is a roll everywhere but the final close.
The final close arrives by calendar alone. A commissioner may settle over any field, down to one: the tally over a single submission assigns that creator the whole peer pool, and the award may join it. An empty field releases all pledges without notice, and so does a prevailing no-award (2.4). A non-empty field met with silence settles the whole pot by the tally alone.
One exit exists before the final close. A commission with an empty field may withdraw on thirty days’ public notice: the notice closes the commission to submissions, and the pledges release when it expires. The first submission ends the option; from then on the pledge holds until settlement or the final close (Section 4, the small field).
Each commission declares its ballot form at posting (Section 1). At small scale, each voting creator distributes 100 points across the other submissions, and each creator’s share of the peer pool is proportional to the points the others gave them. At larger scale, where no voter can attend to every entry, each voter ranks their top five: first choice earns five points, down to one; the tally sums each submission’s points across all voters and converts them to percentages, which divide the peer pool. Clients present each voter the field in their own randomized order, so no entry enjoys positional advantage. Ranking five of a hundred is gameable at the margins and blind to entries a voter never saw; randomized exposure converts most of that bias into noise.
Only ballots cast within the settling occasion’s voting window count. Earlier ballots stand on the record as drafts, recast by reference from a fresh ballot event. Within the window the tally counts each voter’s latest ballot, ordered by the vote’s own timestamp (Section 4, timestamps). Over a field of two or more, a voting window that closes with no ballots cast produces no tally: a commissioner who settles over it awards only their half and the peer half releases, and silence at the final close releases the whole pot. A field of one needs no tally; its lone submission takes the peer pool (2.3).
Every ballot carries a no-award option as one more entry to score: points or a rank may go to it. If no-award’s tally total exceeds every submission’s, the occasion rolls, and at the final close the pledges release (2.3). Otherwise its points are discarded and shares divide over the submissions’ points.
Each commission’s declared minimum payout (Section 1) is a floor, in sats: tally shares below it redistribute to the smallest shares above it. Shares settle in whole sats by largest remainder, so the split sums exactly to the pool. A proportional split across a large field otherwise produces tail shares smaller than the cost of delivering them, since Lightning payments below a few sats are uneconomical to route.
Co-patrons join a commission by pledging publicly. No pooled fund ever exists: at settlement, each pledger pays their own pledge directly, half toward the commissioner’s award, half toward the tally’s result. Co-pledgers acquire no vote: the peer vote belongs to the creators (2.4) and the award belongs to the commissioner (2.2). Whether added stake should carry any influence is open (PROBLEMS.md).
Every role in this document, commissioner, pledger, creator, voter, comes down to signed events, and no event asks whether a human signed one: an AI agent with a key and a Lightning balance participates under the same rules as anyone, and the protocol cannot tell agents commissioning humans from humans commissioning agents. Admitting agents makes sybil attacks cheap; Section 4’s voting trilemma is the resulting central open problem.
Commissions compose. A creator answering a commission may post commissions of its own: the score for a commissioned film is itself a commission, the orchestration of the score another. Each sub-commission is an ordinary commission under every rule in this document: its poster is its commissioner, its own split applies, its own field votes, and its settlement flows patron to creator at that level. Value attenuates as the tree descends, since each level’s creators keep part of what they win and commission the rest, and every commission enforces its own minimum payout (Section 1).
Some commissions ask for a single large work that cannot sensibly be made on spec: a mural, a feature film, a building. Above the on-spec threshold (Section 1), creators submit proposals rather than finished works. The commissioner chooses who executes and judges the milestones, paid in stages.
Creators keep copyright. Commissioners receive a perpetual, non-exclusive license to the winning work. Both terms attach at the moment of submission.
The protocol is neutral the way SMTP is neutral: it routes commissions without reading them, and no party, including its author, can prevent one. Refusal lives outside the protocol, in the clients that choose what to display and the infrastructure that chooses what to carry; the reference client at ordain.art curates its board. A commission that no client displays reaches nobody.
The substrate is Nostr, which already provides the three things the coordination layer needs: signed public events, a federated relay network no one controls, and Lightning settlement native to the ecosystem through zaps. The protocol itself is substrate-independent; this is its first expression, the one the reference implementation targets. Nothing here requires new cryptography.
A creator never needs to know this layer exists. Their entire experience remains: brief, work, Lightning address, payment.
Commission events. Content is the brief; tags carry the settlement terms of Section 1, the named relay set (3.2), and the commissioner’s settlement address. The commissioner is whoever signed the event.
Pledge events. Reference a commission event, signed by the pledging patron, carrying the pledged amount. The commission’s headline number is the sum of its pledge events.
Submission events. Reference the commission, signed by the creator; content is the work itself where size allows, or a reference to the hosted work with a cryptographic hash for verification; tags carry the creator’s Lightning address. Settlement pays the key’s currently published payment address, the profile metadata Nostr already maintains, and falls back to the submission tag where the profile lacks one: Lightning addresses rot, and rolls can put months between submission and settlement.
Vote events. Reference the submissions scored, signed by the voter, revisable per 2.4. Votes publish as ordinary events, never as Nostr’s replaceable kind, which would let relays discard the superseded history the closing set needs; every revision stays auditable. A voter’s submission event establishes their standing.
Closing events. At most one per commission, signed by the commissioner, published at whichever occasion (2.3) they answer with it. The closing event declares the division of the commissioner’s half among the submissions they chose and states the tally result over the closing set. It is the canonical result that settlement clients read, and it is how a commissioner settles; its absence is a roll (2.3), so the protocol needs no roll event. A closing event that misstates the tally is checkably false (3.2).
Window events. Signed by the commissioner, valid under the conditions of 2.3. A valid window event opens a settlement window whose occasion fixes at its timestamp plus the declared window length, identical in mechanics to the window the threshold opens.
Withdrawal events. Signed by the commissioner, valid only while no submission event references the commission. A withdrawal event closes the commission to submissions and releases every pledge thirty days after it publishes.
Settlement as zaps. Settlement follows the closing event: payments go out as NIP-57 zaps referencing the winning submission events. The recipient’s Lightning service signs the zap receipt, so what a stranger verifies is an attestation carrying that service’s trust; a settlement proof that trusts no one is undesigned (PROBLEMS.md). The receipt chain is public and tied to the vote that produced it.
Relays drop events, censor, and disappear, and no relay guarantees completeness. Each commission event therefore names its relay set, and participants publish every protocol event to all named relays. The closing set is the union of protocol events present on the named relays when the field fixes for the settling occasion (2.3), and the tally is a deterministic function of it: any stranger reading the same named relays at close computes the same winners. Relay failure or censorship inside the named set can make two honest readers disagree about the record (PROBLEMS.md, closing-set consistency).
The coordination layer delivers every property of Section 2 except those marked [commitment layer]; settlement fires client-assisted, each pledger’s client reading the closing event and paying its zaps against it.
The deliverables of a reference implementation: the event kinds, open tally-verification tooling any stranger can run, and a reference client. ordain.art becomes one client among several.
Kind numbers are unassigned in this draft. The specification defines semantics; numbers belong to the reference implementation. The NIP draft in the repository is an extract of this section, not a submission to the standards process; a formal NIP follows working software in two clients and a relay, per Nostr convention.
The commitment layer comes first: everything marked [commitment layer] waits on it, and so does any pledger the commissioner does not know.
The commitment layer. Nothing in production locks a pledge the way 2.1 requires: no custody, winners unknown at lock time. The candidate directions, covenant constructions, discreet log contracts, adaptor signatures releasing payment on an attested tally, each carry open questions about who attests the tally, what a lock does across rolls and a standing period of unbounded length, how the empty-field release (2.3) fires without an enforcer, and how a locked pledge splits across a proportional payout to many winners at once.
Pledges at scale. A pledge locked on Lightning is a payment held open until settlement, and a held payment occupies channel capacity for as long as it waits; a channel carries at most a few hundred at once (483 per direction under current limits). A commission with thousands of small pledges outstanding, which 2.1 permits and a standing period of months makes likely, cannot be locked pledge by pledge on today’s network. Whether the answer is aggregation, a different locking construction, or a bounded pledge count is open.
Timestamps. A Nostr event’s signer asserts its timestamp, so “submitted before close” and “voted before close” are not enforceable from event data alone, and the settlement terms inherit the weakness, since the field threshold counts submission events whose timestamps are equally self-asserted. Candidate mitigations, relay-receipt attestations and anchoring the closing set with OpenTimestamps, each reintroduce a trusted party or a latency cost. The closing-set rule in 3.2 narrows the exposure.
The voting trilemma. Of three desirable properties, pseudonymous identity, free submission, and a binding peer vote, any system gets two. Pseudonymous identities plus free submission means an attacker manufactures voters; a binding vote then pays the attacker. In a protocol where agents are first-class participants, manufacturing identities costs nothing, so the trilemma must be settled before any vote is binding at scale. The current method holds all three properties only because the field is small and known, a social solution the protocol cannot inherit. The leading candidate break is cost-to-submit, a small Lightning fee that prices out sybils without testing for humanity. The right price, who receives it, and whether any fee deters the first-time creator in a low-income economy, the protocol’s primary constituency, remain open. A submission fee is also a payment trail linking the submitting key to a funded wallet, and the design has not reconciled that with pseudonymity. Reputation-weighted voting is the other candidate, and it waits on portable reputation (PROBLEMS.md).
The small field. A binding peer vote assumes a field large enough that collusion costs more than it wins; a standing commission can settle over a field of two or three, where a pair of low-effort submissions can rank each other first and take the peer pool from the work that actually fulfilled the commission, and where a low-effort submission, once posted, holds its claim until the final close. The commissioner’s roll (2.3) is the working defense, and reputation covers the remainder for now. Neither survives scale. No tally rule can discount collusive rankings without judging quality, since a function of the ballots alone cannot distinguish a colluding pair from two honest voters who agree, so the defenses live outside the tally: the commissioner’s roll, the discretionary half (the honest submitter’s guaranteed floor), and the threshold read as a security parameter, where against a feared collusion of size c a board wants c plus 2 submissions for one honest scorer and 2c plus 2 for an honest-majority electorate. One low-effort submission also ends the commissioner’s withdrawal option (2.3) and holds the pledge to the final close.
Many-to-many settlement. At settlement, every pledger pays every winning creator their proportional share. With three pledgers and twelve earning creators, that is thirty-six payments that should succeed or fail as one; at the root of the tree the design intends, a million patrons settling one commission, it is millions of payments per level, compounding downward through every sub-commission. Lightning handles individual payments and provides no atomicity across a set. Partial settlement failure, retries, and the reconciliation of a half-settled commission need a defined answer at small scale; at full scale the answer almost certainly involves aggregation the protocol has not designed. Candidate directions: BOLT12 offers for repeatable payment flows, batched delivery, and, at the leaves where shares approach the routing floor, ecash mints as a bearer layer over Lightning. Each reintroduces trust the design would have to account for.
Nine further problems, from settlement attestation to portable reputation, live in PROBLEMS.md in the repository.
Ordain today is an information page and a set of hand-run commissions at ordain.art, a static site with no backend and no payment infrastructure. The author of this document coordinates submissions, computes the tally by the rules in 2.4, publishes results, and arranges settlement by hand, patron to creator, over Lightning. The board is simpler than Sections 2 and 3: it exists to prove the mechanism with real money and real strangers.
Round 1 opened February 23, 2026, with five founding commissions totaling about $2,600. Its June 30 deadline passed without a settlement: most commissions drew no submissions, and no commissioner judged their field ready. The commissions converted to standing under the rules in 2.3. In July 2026 one founding commission was awarded in full: its commissioner awarded the $1,000 directly to a single submission, electing not to run a settlement window over a lone qualifying entry. The remaining commissions stand. The full mechanism this document specifies, a window, a vote, a closing event, has not yet completed a cycle end to end. When a standing commission settles that way, the results publish in full: vote totals, percentages, and a payment receipt for every payout.
Ordain also co-presented the Future of Money AI Film Contest with Bitcoin FilmFest and MoneroKon at the festival’s fourth edition in Warsaw. Its main track concluded June 7, 2026, by a live audience vote and paid 1,500,000 sats to its winner. The contest ran on the festival’s rules rather than this document’s mechanism.
The guarantees at this stage are social.
The canonical version of this document lives at ordain.art/protocol, with a versioned copy in the public repository at github.com/anbealbocht/ordain. The repository also carries the companion artifacts: the NIP draft, a reference tally implementation with signed test vectors, the extended problems list, and the design studies behind 2.4 and Section 4. Everything Ordain publishes is MIT-licensed and public.
This is a draft. Please argue with it.