BSV USA Association: Membership Registry and Voting System

Builder and point of contact: John Calhoun (@johncalhooon), Director. John builds it on his own time and at his own cost, free to the association, and the group can shape it. It is not a request for money.

Summary

The association needs a membership roll that institutions can trust and members can check. This document specifies one. A person joins by proving they control an X account and a BSV key. After 90 days, a member can apply to vote. Each verified person gets one vote. Holding or locking BSV never buys votes. A member who wants to stand for the board may lock BSV in their own wallet as a sign of commitment. The association never holds that BSV. Every roll, ballot set, and result is hashed and written to the BSV chain, and a public page lets anyone recompute those hashes.

This design came out of the organizers' governance discussion in October 2026. One proposal asked for verified identity, a 90-day wait before voting, a small review committee, staggered board terms, no purchased influence, and election records anchored on BSV. Another view held that members should lock BSV to vote. An objection followed: a wealthy party could lock coins through a confederate and buy influence. The compromise this spec adopts is that holding is a board requirement, not a voting requirement.

1Goals and non-goals

Goals

1. One verified person, one vote. Each natural person holds at most one voting membership.
2. No purchased influence. Money, donations, and BSV holdings never add votes or weight a vote.
3. Skin in the game for directors only. A director candidate shows commitment with a self-custodied lock. Voters do not need one.
4. The association never custodies anyone's coins. No pooled wallet, no escrow, no staking contract.
5. Everything auditable by anyone. The roll, each ballot set, and each result can be recomputed from public data and checked against the chain.

Non-goals

• Proving legal identity to the public. Legal names stay private with the Secretary.
• Running a token, a treasury contract, or on-chain governance that executes itself.
• Replacing the bylaws. The system carries out rules the bylaws set. It does not make them.
• Serving every possible member at launch. Version 0 assumes members have an X account and a BRC-100 wallet. Section 3 covers exceptions.

2Actors

The Secretary and the committee are separate roles. No one person should hold both a committee seat and the Secretary's keys.

3Identity verification

The goal is to tie one real person to one X account and one BSV key, and to make that tie checkable by anyone without publishing private data.

3.1 Prove control of an X handle

Two methods. The registry uses both when it can and compares them.

• Post a one-time code. The registry issues a code such as bsvusa-join-7Q4K-2026. The applicant posts it from their X account. The registry reads the post and checks the author, the code, and that the post is less than 24 hours old.
• Sign in with X (OAuth 2.0). The applicant authorizes the registry with the read-only user scope. The registry receives the numeric X user ID, the current handle, and the account creation date.

The registry stores the numeric X user ID as the true identifier, not the handle. Handles can change. The ID does not. If both methods are used, the user ID from OAuth must match the author of the code post. A mismatch sends the application to manual review.

Cost note: the X API has paid tiers and changes its terms often. Version 0 can run on the code-post method checked by the Secretary by hand, with no API spend. OAuth is added later if John chooses to carry the API cost.

3.2 Bind a BSV identity key

The applicant's wallet signs a challenge that names their X user ID:

BSV USA Association membership binding
x_user_id: 1234567890
handle: @example
nonce: 9f3c...e1
issued: 2026-10-12T15:00:00Z

Two signing paths are accepted:

• BRC-100 wallet (preferred). The registry page calls the member's wallet (for example MetaNet Client on localhost:3321) to get the identity public key and to create a signature over the challenge. The registry checks the signature against that public key.
• Plain message signature. For members without a BRC-100 wallet, a standard Bitcoin signed message from a key they control. The registry stores the public key it recovers.

The bound key becomes the member key. It signs ballots, it proves lock ownership, and it signs any later change requests.

3.3 Uniqueness rules

• One X user ID per key, and one key per X user ID.
• A member can rotate their key by signing the change with the old key, or through manual review if the old key is lost (Section 8).
• A person may not hold two memberships through two X accounts. The application asks the applicant to affirm this. Voting members also give their legal name privately (3.6), which lets the Secretary catch duplicates.

3.4 Account checks

These are screening signals, not automatic rejections. The bylaws should publish the thresholds.

• Account age. Suggested starting point: at least 6 months old.
• Activity. A history of public posts, not a fresh or dormant account suddenly revived.
• Consistency. Name, bio, and history that fit the person applying.
• Relevant work. Posts about BSV, things built, events attended. This counts in favor but is never required, because the association should welcome newcomers.

3.5 Manual review

The committee reviews any application that fails a check, any mismatch between methods, any applicant without an X account, and any applicant a member flags. Two of three committee members decide. A refusal comes with written reasons. The applicant can appeal under the bylaws.

People without an X account can apply through manual review with another public profile or an in-person or video check. The bylaws should say what is accepted.

3.6 What is stored where

Board candidates make their conflict disclosures public. Other members' disclosures stay private.

4Optional lock

4.1 What a lock is

A lock is a BSV output the member creates in their own wallet. It cannot be spent until a chosen block height. Only the member's key can spend it after that height. The association never holds it and never can.

4.2 The script form (verified)

The original OP_CHECKLOCKTIMEVERIFY opcode is not available on BSV. The Genesis upgrade in February 2020 turned OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY back into no-ops (BSV wiki, Genesis upgrade). So a "CLTV-style" lock on BSV is enforced a different way.

The existing BSV lock protocol, used by HODLocker and others, is an sCrypt contract that uses the OP_PUSH_TX technique. The spender pushes the transaction's own signature preimage onto the stack. The script checks that the preimage is genuine and that the spending transaction's nLockTime is at or past the locked height (CoinGeek, "Timelock Bitcoin and tokens via sCrypt", May 2021; sCrypt, OP_PUSH_TX).

The current open-source reference is the 1Sat SDK Lock template (b-open-io/1sat-sdk, packages/templates/src/lock/lock.ts). Its locking script is:

<LOCK_PREFIX>  <owner public key hash, 20 bytes>  <until, block height, little-endian>  <LOCK_SUFFIX>

LOCK_PREFIX and LOCK_SUFFIX are fixed byte strings from the compiled sCrypt contract. To spend, the owner builds a transaction with nLockTime set to the locked height or later and the input's sequence number below the maximum (the SDK uses 0). The unlocking script is an ordinary signature and public key plus the signature preimage.

The registry will use this template as is. It will not write its own contract. Using the protocol the ecosystem already indexes means existing wallets and explorers can show the lock.

4.3 What the registry verifies on chain

When a member registers a lock, they give the transaction ID and output index. The registry:

1. Fetches the transaction and confirms it is mined (via a Merkle proof or a block header service).
2. Decodes the output with the Lock template and confirms the prefix and suffix match.
3. Reads the amount in satoshis and the until height.
4. Confirms ownership. The public key hash in the script must equal the hash of the member's bound key, or of a key the member proves by signing a fresh challenge. Either way, the member signs a statement linking that output to their membership.
5. Confirms the output is unspent, and checks again before every board election and on a schedule.

A lock counts only while it is unspent and its height is in the future. Locks that expire mid-term are handled by the bylaws (Section 10).

4.4 What the registry never does

• It never asks for a private key, a seed, or a signature that could move coins.
• It never builds a lock that pays to any key but the member's.
• It never holds, moves, pools, or lends coins.
• It never publishes a member's other wallet balances.

4.5 How unlock works

When the height passes, the member's own wallet spends the output back to themselves. The association has no part in this. The 1Sat SDK and wallets that support it can unlock all matured locks in one action. If a member spends the lock, the registry sees it and removes the badge.

4.6 What a lock buys

• Director eligibility, if the bylaws set a minimum amount and minimum remaining time.
• A public badge on the roll showing the amount and the height.

It never buys extra votes, a heavier vote, a faster path to voting membership, or a guaranteed seat.

4.7 The deep-pocket objection

The objection: a wealthy party, such as an exchange, could lock a large amount through a friendly person and look committed. The answers:

1. A lock buys eligibility, not a seat. Seats are won in elections where each verified member has one vote, however much they lock.
2. No bonus for size. Above the minimum, a bigger lock gains nothing. Outbidding is pointless.
3. The committee can refuse a candidate, with written reasons and appeal, on grounds the bylaws list, such as an undisclosed conflict or acting for an undisclosed principal.
4. Disclosure. Candidates must disclose employers, funders, and anyone who supplied the locked coins. Coins from a third party must be disclosed, and the bylaws can bar them.
5. Caps on related parties. No more than one director (or a set share of the board) may be tied to the same company, funder, or family.
6. Removal. A false disclosure is grounds for removal under the misconduct rules.

5Member classes and the 90-day clock

The 90-day clock

• The clock starts on the date the member is approved as a general member. That date is public on the roll.
• At day 90 the member may apply for voting membership. This needs: legal name given to the Secretary in private, agreement to the bylaws and mission, conflict disclosures, and some record of taking part (meetings, outreach, projects).
• Voting eligibility for a ballot is fixed at the ballot's snapshot time. A member who reaches voting status after the snapshot votes on the next ballot.
• For constitutional votes (changing the mission, dissolving, changing voting rules), the bylaws should require an extra 90 days of voting membership.
• Voting membership renews each year. Renewal is a signed statement from the member key that the details still hold.

Founding period

Before 90 days have passed for anyone, there are no voting members. The bylaws must name a temporary founding committee and say how the first board is formed. That committee's term should end at the first election.

6Voting

6.1 Proposal lifecycle

1. Draft. A director or a set number of voting members submit a proposal.
2. Published. The Secretary posts the text, the options, the ballot type (open or secret), the threshold (majority, two-thirds, 75%), and the quorum. The text is hashed and the hash goes in the eventual anchor.
3. Discussion. A set period. The bylaws should say how long (suggest 7 days; 14 for constitutional votes).
4. Snapshot. At a stated time, the registry freezes the list of eligible voting members. It publishes the roll and its hash.
5. Ballot window. A set period for voting (suggest 7 days).
6. Close and tally. The Secretary closes the window and the registry counts.
7. Publish and anchor. Results, the ballot set (or its commitments for secret ballots), and the hashes go public and on chain.
8. Dispute window. A set period (suggest 7 days) to challenge the result.
9. Final. If no dispute succeeds, the result is final.

6.2 The ballot

A ballot is a small JSON document signed with the member key:

{
  "v": 1,
  "proposal_id": "P-2026-004",
  "proposal_hash": "sha256:...",
  "snapshot_hash": "sha256:...",
  "member_key": "02ab...",
  "choice": "yes",
  "cast_at": "2026-11-03T18:20:00Z"
}

The registry checks that the key is on the snapshot roll and that the signature is valid. A member may replace their ballot during the window. The last valid ballot counts. All replaced ballots are kept and published with a flag.

Signing in the browser uses the BRC-100 wallet's createSignature call. A member with a plain key can sign the canonical JSON with a standard message signature and upload it.

6.3 Tally

• The tally counts one ballot per member key on the snapshot roll.
• Ballots from keys not on the roll, with bad signatures, or cast outside the window are rejected and listed with a reason.
• The tally program is open source. Anyone can run it on the published ballot set and get the same answer.

6.4 Publication and anchoring

For each vote, the registry builds:

• Roll root. The SHA-256 Merkle root of the snapshot roll. Each leaf is one member's canonical record (member ID, X user ID, member key, class, eligible-since date).
• Ballot root. The Merkle root of the final ballot set in canonical form.
• Result hash. The SHA-256 of the canonical result (counts per option, rejected count, threshold met or not).

It then writes one transaction with a data output:

OP_FALSE OP_RETURN "bsvusa.v1" "vote" <proposal_id> <proposal_hash> <roll_root> <ballot_root> <result_hash>

The output is paid for from a small association operating wallet that holds only fee money, never member coins. The anchor key's public key is published so anyone can confirm which transactions are official.

Anyone can then:

1. Download the roll, ballots, and result from the public endpoints.
2. Recompute each root and hash.
3. Find the anchor transaction on any BSV explorer and compare.
4. Check every ballot signature.
5. Check their own ballot is a leaf in the ballot root, using the published proof.

Membership changes are anchored the same way, in a periodic roll anchor (suggest weekly), so the roll's history cannot be silently rewritten.

6.5 Open and secret ballots

Recommendation: open, signed ballots for board elections and ordinary proposals. Secret ballots only where the bylaws require them.

Why open by default: open ballots are the only kind that anyone can fully check with simple tools. Every signature and every count is public. For an association whose first job is to pass outside due diligence, that is worth a lot.

The cost of open ballots is pressure. People can see how others voted. The bylaws should list the votes that must be secret, such as removing a director or disciplining a member.

How a secret ballot works in this system (v1):

1. The bylaws name an independent election inspector who is not a director, the Secretary, or on the committee.
2. Each voter signs a ballot as usual, then encrypts it to the inspector's public key. The voter also picks a random secret.
3. The registry publishes, for each voter, only a commitment: the hash of the encrypted ballot plus the voter's secret. It also publishes who voted, but not how.
4. After close, the inspector decrypts, checks signatures and the roll, and publishes the counts and a shuffled list of plain choices with no keys attached.
5. Each voter can confirm their commitment is in the published set. The inspector signs a statement that the counts match.

This is weaker than an open ballot. Voters must trust the inspector not to reveal choices or miscount. Stronger cryptographic schemes exist, but they are harder to build and to explain. They could replace this in a later version if the bylaws call for it.

6.6 Recounts and disputes

• Recount. Anyone can recount from the public data at any time. A formal recount is just the Secretary rerunning the tally in public and confirming the hashes.
• Disputes. Any voting member can file a dispute in the dispute window, signed with their member key. Examples: an eligible member was left off the snapshot, a ballot was wrongly rejected, an ineligible key voted.
• Who decides. The committee decides with written reasons. If a committee member is involved, they recuse. Appeals go where the bylaws say.
• Corrections. A corrected result gets a new anchor that points to the old one. Nothing is deleted.

7Privacy and data retention

• Public by design: handle, X user ID, member key, join date, class, badges, lock outpoints and amounts, open ballots, results, anchors.
• Private: legal names, emails, private disclosures, review notes. Encrypted at rest. Access limited to the Secretary and the committee, and every access is logged.
• Not collected: government ID images, addresses, phone numbers, wallet balances beyond a registered lock. If the bylaws or law later require ID checks, use a third-party verifier that returns a pass or fail and keeps the documents.
• Retention:
• Rejected applications: private data deleted after 12 months.
• Former members: private data deleted 24 months after leaving, unless a dispute is open. The public roll keeps a "former member" record, because anchored rolls cannot be rewritten.
• Election records: kept for good.
• What cannot be erased. Anything anchored is on a public chain forever. That is why only hashes and public fields are anchored, never private data. Members must be told this plainly before they join.
• Member rights. A member can see their own private record, correct it, and resign. Resigning ends future participation. It does not remove past public records.

8Threat model

9Architecture

9.1 Components

• Registry API. A Cloudflare Worker. Handles applications, challenges, signature checks, ballots, and admin actions.
• Storage. Cloudflare D1 (SQLite) for structured records. R2 or KV for published snapshot files. The Secretary's private fields are encrypted before they reach D1, with a key the Worker does not hold at rest.
• Wallet-signing flow. A small web page that talks to the member's BRC-100 wallet (MetaNet Client on localhost:3321 or any compatible wallet). It gets the identity key and signs challenges and ballots. A paste-in form handles plain message signatures.
• Chain reader. Looks up transactions, Merkle proofs, block headers, and spent status for lock checks and anchor checks. Uses a public BSV service. Results are cached.
• Anchor writer. A separate job, run by the Secretary, that builds the anchor transaction from the computed roots and signs it with the association's anchor key. Kept apart from the API so a compromise of the API cannot write anchors.
• Public verifier page. A static page. It downloads the public files, recomputes every hash and Merkle root in the browser, checks ballot signatures, fetches the anchor transactions, and shows pass or fail for each step. It has no server logic.
• Read-only public endpoints. Plain JSON, cacheable, no login:
• GET /roll and GET /roll/{snapshot_id}
• GET /members/{member_id}
• GET /proposals and GET /proposals/{id}
• GET /proposals/{id}/ballots
• GET /proposals/{id}/result
• GET /anchors
• GET /locks
• GET /audit-log

An x402-style paid agent could later offer bulk exports or a hosted verifier for institutions. It is not needed for any member function. Members never pay to vote.

9.2 Data model

Canonical forms: all hashed JSON uses sorted keys, no extra spaces, and UTF-8. The spec for canonical form and Merkle leaf order is published with the verifier so anyone can rebuild it.

10Build plan

Rough effort assumes one builder part-time with AI assistance. These are estimates, not commitments.

v0: Registry (about 2 weeks)

• Join flow: one-time code post, checked by the Secretary; key binding by BRC-100 signature or plain message signature.
• Public roll page and GET /roll.
• Admin screen for the Secretary and committee: approve, refuse with reason.
• Private record store for legal names (empty until voting starts).
• Audit log.

Bylaws must say: who can join; the account checks; the committee's makeup and two-of-three rule; the appeal path; what is public and what is private; how the founding committee is chosen and when it ends.

v1: Voting (about 3 weeks)

• Proposals, snapshots, ballot window, signed open ballots, tally, publication.
• Voting membership applications at day 90; annual renewal.
• Disputes.
• Secret ballot path through an independent inspector.

Bylaws must say: who can propose; notice, discussion, and ballot periods; thresholds and quorum; which votes are secret; the inspector's selection; dispute and appeal rules; the extra 90 days for constitutional votes; how the board is elected and staggered.

v2: Lock verification and director eligibility (about 2 weeks)

• Lock registration with on-chain checks against the 1Sat Lock template.
• Scheduled spent-status checks; badges on the roll.
• Candidate filing with public disclosures; committee review of candidates.

Bylaws must say: the minimum lock amount and minimum remaining time for candidates; whether third-party coins may be used; related-party caps; what happens if a director's lock expires or is spent mid-term; grounds for refusing a candidate.

v3: Anchoring and verifier (about 2 to 3 weeks)

• Merkle roots for rolls and ballot sets; anchor writer; weekly roll anchors.
• Public verifier page.
• Published canonical-form spec.
• Optional: OAuth sign-in with X, if John chooses to carry the cost.

Bylaws must say: that anchored records are the official record; who holds the anchor key and how it is rotated; how corrections are anchored.

Anchoring could move earlier, to v1, if the organizers want the first vote anchored. The cost is about a week.

11What the system is not

• Not a token. Members get no coin, share, or point. Nothing in the system can be bought, sold, or traded. The member key is just a signing key the member already owns.
• Not a DAO. Nothing executes on its own. People elected under the bylaws make decisions. The chain is used only as a public notary for hashes.
• Not a securities offering. No one gives the association money or coins in hope of profit. Locked coins stay in the member's own wallet, earn nothing, and return to the member. The association promises no return and pools nothing. Membership fees, if the bylaws set any, are ordinary association dues, not an investment.
• Not a custody service. The association never holds, moves, or controls member coins. It cannot recover a lost key or freeze a lock.
• Not a proof of loyalty. A lock shows a candidate's commitment. It does not decide who is a good member. Disagreement and criticism are never grounds for losing a vote.

Counsel should confirm these points (see the questions below).