BUIP221: Delegate Operational Matters to the BU Executive

BU
1

BUIP221: Delegate Operational Matters to the BU Executive

Submitted By: Andrew Clifford and Andrew Stone
Date: 29 January, 2026

1. Summary

The original intention of the BUIP system was to give the BU membership control of the election of the BU officers “Executive” and guide the functional and technical direction of the full-node client software and associated satellite systems. That will always remain. However, over time, BUIPs have come to be raised for operational matters such as conferences, exchange listing, marketing, and also individual staffing roles.

2. Motivation

In order to give Nexa every chance of success, it has been necessary to increase the team size by almost 3x. Most of whom are developers of varied skill-sets, but also some specialist operational staff.

It has also been necessary to seek exchange listings, seek promotional media relationships, sponsor and attend conferences, all of which require a budget, funding and ongoing time and effort to service.

With the large team size and the many different operational matters, which occur each month, it is unwieldy to use the BUIP system outside its original intent.

There has always been the ability for members to raise “counter-BUIPs” to oppose a development proposal. This can also apply for any operational matter. The control will remain for the ability of a member to raise a BUIP overriding or modifying an Executive operational decision.

3. Proposed Action

The Executive to be authorised by the membership to manage operational matters, i.e. delegated, to handle such matters day-to-day and ad-hoc. This includes

  • Seeking exchange listings, promotional media relationships, sponsoring and attending conferences, events

  • Maintaining adequate staffing levels for both developers and non-developers

This is in order to provide flexibility, reduce delta, and maximise our ability to promote Nexa while maintaining good governance.

In the event of a successful counter-BUIP to an Executive operational decision, the decision will be reversed as much as practicable.

2

I understand the desire to consolidate decision making processes for these matters. The team and the project is scaling. We all agree on wanting the best possible outcome for Nexa, and the projects that Bitcoin Unlimited is working on.

I note that many of the operational items this BUIP proposes to delegate to the Executive, are fundamentally marketing and business decisions with long-term strategic impact for Nexa.

I would like to clarify some points about this BUIP to understand it better.

Seeking Clarification

Last year, no BUIPs were raised for conferences or marketing initiatives, which meant members not directly involved in marketing had no formal forum to provide input or raise their concerns. While it is appropriate for designated teams to manage their relevant tasks and departments, a core value of Bitcoin Unlimited’s decentralised nature has always been the creation of open discussion and seeking consensus around major decisions, including operational ones.

This is just one example for context about why I would like to seek clarification, and I believe there are some parallel cases that exist on the development side as well.

I would encourage developers in the BU membership to engage in this conversation too.
**
This leads me to 3 questions, please:**

  1. Under the proposed BUIP, operational decisions in the mentioned categories would be fully delegated to the Executive without consensus. Does this represent an intentional shift toward a more centralised decision-making model organisation-wide, and if so, how is broader member input expected to be captured and incorporated going forward?
  2. Are you altering the company articles to remove Operational BUIPs?
  3. Are you planning to introduce any formal internal processes or conflict resolution pathways to support the scaling team, so that minor or non-urgent matters can be resolved outside of the BUIP forum?
3

I do think part of the reason the voting process can be tiresome is the lack of accessibility and how manual parts of it can be. In the past, marketing budgets and even hiring were handled via BUIPs, and I don’t think this system should be scrapped. It also brings more transparency to the community.

4

I do not understand the claim made in this BUIP that “over time, BUIPs have come to be raised for operational matters”.
BUIPs have always been used for operational matters and other things unrelated to BU officer elections and the full node including but not limited to staffing, how to manage BUs funds, participating in events/conferences, BU processes and policies in general, and other non full node projects.
The first time a BUIP was used for operational matters was in BUIP025: BU “Bronze Sponsor” at Scaling Bitcoin, Milan, Italy posted in August 2016 by Solex less than 1 year from the founding of BU (the date of the first BUIP).

In the original articles of confederation (prior to formal BU company formation) BUIPs on operational matters were specifically mentioned

original_artilcles_buips
original_artilcles_buips1431×452 98 KB

and are continued under the general BUIP as a choice for a type of BUIP in the current BU company articles (operational things do not fall under the scope of other outlined BUIP types).

general_buip
general_buip1182×350 17.5 KB

Why outline/define these if they were not intended for use?

Of the 220 BUIPs that have been created thus far (BUIP 9 was never used) at least one third (~35%+ depending on how you categorise a few of them) of them have either been firmly or partially in the operational category. For clarity, when I say “partially in the operational category” I mean BUIPs that have been about allocating funding (an operational matter) for a development project unrelated to the full node without a full technical specification on how the project is to be done.

Operational BUIPS (count: 62)
-BUIP025: BU “Bronze Sponsor” at Scaling Bitcoin, Milan, Italy
-BUIP026: (passed) Bounties for Software Exploits
-BUIP027: (passed) Satoshi’s Vision - Development & Scaling Conference
-BUIP034: (passed) Ecosystem Outreach for Onchain Scaling
-BUIP043: (closed) Exploring the Bitcoin Network
-BUIP044: Development Process
-BUIP046: (passed) Faster, Higher Quality Publication Process for the Bitcoin Research Journal Ledger
-BUIP062: Funded Development, aka Devpool
-BUIP066: Ecosystem Outreach for Onchain Scaling, Part II
-BUIP068: (passed) Satoshi’s Vision 2 - Conference
-BUIP069: Academic paper - Mining, Taxation and Public Goods in Bitcoin
-BUIP071: (passed) Make Bitcoin Cash the “Release” Version of Bitcoin Unlimited
-BUIP072: Partially re-weight BU’s funds towards BCH
-BUIP073: (closed) Fully re-weight BU’s funds towards BCH
-BUIP074: Sell the Bitcoin Gold portion of BU’s funds for BCH
-BUIP089: (passed) Blockchain Engineer Services Contract
-BUIP091: (passed) Move the official BU repository and issue tracker to GitLab
-BUIP092: (passed) Workshop on Instant Transactions for Bitcoin
-BUIP098: (passed) Bitcoin Unlimited’s Strategy for the November 2018 Hard Fork
-BUIP103: (passed) Let’sBuildBCH! @ Satoshi’s Coffee-house - Conference
-BUIP106: (withdrawn) License Bitcoin Unlimited software under GPLv3
-BUIP111: Use BTC over BCH or BSV
-BUIP121: (passed) Create formal BCH specifications
-BUIP122: (closed) Remove Norway from membership
-BUIP123: (closed) Remove imaginary username from membership
-BUIP125: (passed) Remove Norway from membership
-BUIP127: (closed) Partially re-weight funds, 50% BTC to BCH
-BUIP128: (passed) Fund the Developer
-BUIP132: (passed) Ecosystem Outreach & Marketing for BU & On-chain Scaling
-BUIP134: (passed) Fund another Developer
-BUIP137: (passed) Funded Development, aka Devpool3
-BUIP138: (passed) Fund BU’s Chief Scientist
-BUIP141: (closed) Restrict voting rights for Non-publicly identified members
-BUIP145: (passed) Additional funding for bitcoin cash specification
-BUIP147: (passed) Fund Developer 2
-BUIP148: (passed) Ecosystem Outreach & Marketing for BU & On-chain Scaling 2
-BUIP150: B.U. Incorporated office admin
-BUIP153: BU Blockparty - Let’s Get Building On Bitcoin Cash!
-BUIP157: Continue Funding a Developer
-BUIP159: Ecosystem Outreach & Marketing for BU & On-chain Scaling 2021
-BUIP160: BCH Developer On-ramp System
-BUIP162: The BU Mining Reward Guarantee
-BUIP163: Ongoing Publication Grant to the Journal Ledger
-BUIP167: Hire talent to conduct consensus building work
-BUIP174: Funded Development, aka Devpool4
-BUIP176: Flexibility for Long-term Developers
-BUIP179: Ecosystem Outreach & Marketing for BU & On-chain Scaling 2022
-BUIP184: Nexa Marketing Budget
-BUIP185: Nexa Infrastructure & Strategy
-BUIP186: Mid-Tier Exchange Listing Fee
-BUIP190: B.U. Team NEX Vesting Rewards
-BUIP191: Nexa Growth Plan Community Funded Projects
-BUIP193: Bitcoin Unlimited be a “Customer” for a student project at NTNU
-BUIP194: Flexibility for Long-term Developers 2023
-BUIP196: Marketing Team Budget Increase
-BUIP201: NEXA 1st Hackathon
-BUIP202: Hire additional developers
-BUIP204 B.U. Participation in the Australian Crypto Convention 2024
-BUIP205: Fund Bitcoin Unlimited and Nexa Marketing and Social Media Hires
-BUIP209: B.U. Long-term Mission Focus on NEXA
-BUIP211: Continuing the Publication Grant to Ledger Journal
-BUIP212: B.U. Key Person Self-insurance Policy

BUIPs that are about an operational decision to fund or adopt a development project unrelated to full node (count 17)

-BUIP030: (closed) Website Enhancements at bitcoinunlimited.info
-BUIP035: (passed) New Bitcoin Unlimited Website
-BUIP065: Gigablock Testnet Initiative
-BUIP126: (passed) Planet-on-a-LAN stress test model network
-BUIP129: (passed) Finish and Productize the BU voting system
-BUIP142: (closed) Create Bitcoin Cash testdata
-BUIP152: Announcing Wally Wallet
-BUIP173: Join and support BMP for BCH development
-BUIP181: BU Mobile Wallet Project
-BUIP182: Fund Rostrum Electrum server development
-BUIP187: CashScript Port To Nexa
-BUIP189: Token Minting Tool - Basic
-BUIP195: Nexa UltraScale Testnet Initiative
-BUIP197: BIPs32-39-44 HD functions for Falcon PQC - Public Bounty
-BUIP198: Ledger Embedded App Development
-BUIP199: NexScript Phase 2
-BUIP200: Tokenize Phase 2

I may have missed some BUIPs and not everyone may agree with all my categorisations for the ones I have included but the point is that operational BUIPs are not a new phenomenon and moving all of them under executive discretion is a significant change to how BU has been operating.

The oddity out of historical operations was 2025 when conferences and events were funded without the approval of BUIPs which have been historically required to allocate funding for things.

5

I understand the need for operational flexibility and support the general intent of this proposal. However, I have a couple of concerns that I’d appreciate clarification on.

Transparency and timing for counter-BUIPs

The proposal states that members retain control through the ability to raise counter-BUIPs. However, if operational decisions no longer require a BUIP before action is taken, how will members be informed about these decisions in a timely manner?

For the counter-BUIP mechanism to be meaningful, we would need:

  • A clear process for the Executive to communicate operational decisions to members
  • A reasonable timeframe within which counter-BUIPs can be raised
  • Consideration of what happens when decisions are difficult to reverse (funds already spent, contracts signed, public announcements made)

Without these details, the counter-BUIP safeguard may be more theoretical than practical.

Scope of BUIPs going forward

If this passes, what remains for the BUIP system beyond officer elections and membership? I want to make sure we have a clear understanding of what the BUIP process will be used for.

This is especially relevant if my proposal to split the system into BUIPs, NXIPs, and NRCs moves forward—the combination of both proposals would significantly narrow the scope of BUIPs. I’m not necessarily opposed to that, but I think we should be explicit about it.

6

I agree with the need for operational flexibility and also agree with vgRunners clarification above about having a clear process for the Executive to communicate operational initiatives to members.

My position is that operational initiatives should be communicated to members in advance, with either an immediate endorsement to proceed, or a request for more time to consider the initiative and provide feedback.

The process should be clear and also efficient so that initiatives with good support can proceed without delays. But also, if the executive feels strongly about an initiative they should be able to proceed without seeking full support. My understanding is that membership have voted to appoint people into these executive positions for a term with certain responsibilities and that they should be able to make decisions without requiring full support before proceeding.

7

Section 10 of the company articles clearly outlines the additional responsibilities of the officers beyond those of other members. The officers are voted into their positions with the purpose of executing said responsibilities but they are still bound by the governance structure (BUIPs) laid out in the articles. They do not have the ability to unilaterally make decisions for BU unless a BUIP approves that power which is what this BUIP is asking for. Even their emoluments and repayment for expenses incurred during the performance of their duties require members to pass a BUIP to pay for (sections 10.7 and 10.8).

10.1.1 The President who:
(a)Shall be an Identified Member
(b)Is responsible for the ongoing activities of the Company; and
(c) shall resolve BUIP number conflicts, organize BUIP discussion (in the B.U. Public
Forum, Sealed by the Company), and managing voting (within the limits
specified in these articles).

10.1.2 The Secretary who:
(a)Shall be an Identified Member;
(b)Is responsible for recording activities and vote results, and making this
information publicly available;
(c) Shall keep the records and registers required to be maintained by the Act
(d)Is responsible for creating, maintaining and moderating the B.U. Public Forum
where discussion can be held such moderation being exclusively limited to
moving content with an indication of it being moved not deleting it; and
(e) shall tally and report on votes.

10.1.3 The Developer who:
(a)Shall be an Identified Member;
(b)Is responsible for maintaining the B.U. code repository, choosing which
committers have access to the software repository, reviewing and merging
patches, and periodically releasing B.U. software;
(c) Must actively work to encourage Members to work on submissions, and to
convert one-time submitters into regular committers.

That is the extent of the roles outside of required legal responsibilities set forth in the companies act.

8

I don’t read that this BUIP is asking for unilateral power.
Making unpopular unilateral decisions would result in BUIPs to counter that action.
I see this being used in cases where the action is communicated in advance, there is perceived majority support that would almost certainly pass a BUIP, then the decision is made to proceed without the full process. If there is majority or near majority disagreement then most certainly a BUIP is required, or the initiative amended to address concerns.

9

It gives unilateral power initially with a pathway for decisions to be reversed later by a counter BUIP vote. This is essentially a delayed feedback mechanism. The decision is allowed to take place until much later when a vote can be held to contest the decision. Only after a passing vote would the decision be required to be halted or reversed. The problem with delayed feedback like this is exactly what is written in the last sentence of the proposal

undoing decisions is an attempt not a guarantee. If the decision involved an expenditure of funds, signing of a contract, or anything else that can not be reversed then the resources expended can not be recovered and the feedback mechanism (counter BUIP) effectively does nothing.

Additionally, the suggestion to use the counter BUIP process as the feedback mechanism means that any disagreement MUST now be in the public BUIP process. There is no way to disagree with a decision without letting the entire community know that this disagreement has taken place.