Goosie Club Rules
| screenshot_goosie_club_rules_may_26_verification.png |
| goosie_club_rules_verification_march_26.png |
| verification_of_goosie_rules_21_mar_25.png |
| verification_of_goosie_rules_21_spreadsheet_mar_25.png |
| screenshot_verification_of_goosie_club_rules_may_24.png |
| verification_of_rules_of_goosie_club_april_2024.png |
| screenshot_club_notice_3_june_22.png |
Notice
We of mankind, sometimes acting as operators of Goosie Nodes (Nodes), and together forming the Goosie Private Club (Club), do maintain and operate instances of the Goosie Protocol (Protocol).
We acknowledge that the Protocol contains novel and commercially useful features, and that these features derive their strength from being deployed within a consistent and recognised ruleset.
Accordingly, any man or woman may inspect, use, and deploy the Protocol; however, only those deployments which adhere to the canonical rules of the Club may represent themselves as standard Goosie.
This protects the standard by clarity of identity rather than by trying to prevent others from building software.
1. General
Goosie is a private, rule-based system for Bitcoin-backed, gold-denominated liquidity.
The Club is organised and maintained by the Nodes running a shared Goosie deployment.
The Club does not exist separately from the Nodes. The Club is the collection of Nodes acting in agreement.
All who contribute time, property, infrastructure, liquidity, development, or promotion to the Protocol do so as a man or woman in the private and take responsibility for their own actions.
In simple terms: the Club = the Nodes.
2. Aims
The aims of the Club are to:
- protect the identity and integrity of the Goosie standard;
- deliver the on-going development of the Protocol;
- maintain secure, reliable, and solvent Goosie deployments;
- promote the use of Goosie as a method of payment worldwide.
3. The Node as the Core Unit
A Node is a single instance of the Goosie software run by a man or woman.
The Goosie Private Club is formed when two or more Nodes agree to:
- synchronize a common blockchain ledger;
- share a threshold-signing set;
- apply a common ruleset;
- maintain the same canonical economic parameters.
If a Node adopts incompatible rules, it ceases to be part of the Club and may form or join another deployment.
This means governance happens through Nodes choosing to run compatible software, not through an abstract committee above them.
4. Canonical Rules of the Goosie Standard
The following rules are canonical and define the Goosie standard:
- 1,000 Goosie = 1 ounce of gold;
- new Goosie may be minted only at 51% of gold value;
- Bitcoin is the only accepted collateral unless the canonical rules are changed by a formal standard fork;
- user BTC collateral must remain individually attributable and non-pooled;
- the Protocol does not use forced liquidation;
- a 1% system fee applies on minting and must be distributed according to the canonical fee schedule.
These rules are best treated as canonical rather than casually editable. Changing them is effectively a fork.
5. Governance and Updates
Each Node participates in governance by choosing what software version it will run.
Any Node may propose an update.
An update takes effect for a deployment only when the required Node majority adopts and runs the updated software.
If Nodes disagree, they may continue under separate rule sets as separate deployments.
The real vote is software adoption. Nodes govern by what they run.
6. Open Deployment and Notice of Difference
Any man or woman may deploy Nodes, inspect code, improve code, or operate a new Goosie-derived deployment.
Where a deployment does not follow the canonical rules, those operating it should give clear notice that it is not standard Goosie.
No Node or operator should present a fork or modified deployment as though it were maintained under the canonical Goosie standard when it is not.
This is a cleaner and more durable protection than trying to prohibit all competing deployments.
7. Remuneration Structure
The Protocol applies a 1% fee on minting. This fee is allocated in five equal parts of 0.2% each as follows:
7.1 First Node Reward
0.2% is allocated to the operator of the first Node to reach 5,000 users.
This allocation is perpetual and applies across all Nodes and all standard Goosie deployments.
7.2 Local Node Allocation
0.2% is allocated to the Nodes maintaining the deployment on which the minting occurs.
This allocation is local to that deployment and is intended to fund infrastructure, uptime, signing operations, and direct system maintenance.
Where multiple Nodes maintain the same deployment, this local allocation shall be divided among those Nodes according to that deployment’s node agreement.
7.3 Founder Allocation
0.2% is allocated to Branton Kenton-Dau, sometimes acting as Founder, for original design, architecture, strategy, brand, and ecosystem direction.
7.4 Initial Liquidity Provider Allocation
0.2% is allocated to the initial liquidity provider.
This allocation is perpetual across all standard Goosie deployments, subject to final identification and confirmation of the qualifying liquidity role.
This part may later be refined if more than one initial liquidity provider is recognised or if the qualification test needs tightening.
7.5 Club Maintenance and Marketing Allocation
0.2% is allocated for Club maintenance and marketing.
As the Club is the collection of Nodes, this allocation should be held under the control of the active Node set for that deployment and spent only for the benefit of the system, including infrastructure, security, development, education, promotion, and marketing.
8. Treasury and Control of Common Funds
Any common treasury or maintenance fund of a deployment shall be controlled by the Node set of that deployment.
Such funds should be held under threshold or multi-signature control requiring approval by the relevant Node majority before release.
This keeps common funds aligned with the same Node-based governance model as the rest of the system.
9. Responsibilities of Each Node
Each Node operator shall:
- maintain secure and reliable infrastructure;
- protect its key shard and operational secrets;
- participate honestly in ledger synchronization and signing;
- only authorize BTC release when Protocol rules are satisfied;
- avoid actions that compromise users, other Nodes, or the integrity of the standard.
During the foundational phase, the Founder and early Node operators may coordinate the first deployment, initial infrastructure, initial liquidity, and initial software releases for the sake of stability and security.
The foundational phase does not change the canonical rules, but may simplify early coordination until the network of Nodes matures.
11. Future Governance Evolution
A broader governance layer, including a DAO or other representative mechanism, may emerge in future.
However, the base operation of the Protocol remains grounded in the Nodes, because the Nodes maintain the ledger, operate the signers, and uphold the rules in practice.
12. Statement of Ethos
We of mankind, acting as Nodes within the Goosie Club, do not claim power over the Protocol by title alone.
Rather, we maintain, operate, and uphold a standard through faithful running of the software and the rules.
The strength of Goosie arises not from restriction, but from consistent adherence to its canonical design.
more information: [email protected]