Basic spec for BDFX leadership module

The BDFX leadership OS will have the following features.

1. 1The BDFX leadership OS is a generalized module allowing for leaders and managers of decentralized, unincorporated orgs to have many of the same functional capabilities as incorporated orgs, starting with financial ops (the main focus of this initial spec), as well as voting/decision-making, and contribution tracking for paid/volunteer work (which are partially specified here)
2. 2This is initially specified as a module to be attached to the protoco-institute.org website either as a subdomain or a /bdfx section, using the same authentication and identity system. But it should be designed to be bolted on similarly to any host website that wants this functionality.
3. 3Eventually, this may be redesigned as a decentralized protocol.
4. 4This OS should be blockchain-aware and compatible but not dependent on it.
5. 5For the financial OS component that this is starting from, the main idea is to allow a group of individuals to be able to manage funds on behalf of the unincorporated organization systematically, by acting as prime contractors who disburse funds to subcontractors to compensate for work on projects or for the org's general needs.
6. 6The goal is to do this in a way that's legible to tax authorities, but set up to minimize intermediary tax exposure (by encouraging funds to be zeroed out via subcontracting before the end of every tax year)
7. 7A key idea is to get many of the benefits of nonprofits without actually incorporating, by getting funds to the final recepients within a tax year, so that intermediary parties holding the funds have zero tax liabilities for funds paid to subcontractors.
8. 8The basic scheme will create 2 classes of people, "partners" and "contributors." PI members who are neither will be simply regarded as "members" for purposes of BDFX operations, regardless of any other groups they're in. The only exception is "admins" who are ex officio partners as well with broader rights than ordinary partners.
9. 9This system requires high trust among all participants in the system, and especially among the partners, so best practice will be to only use BDFx with high-trust unincorporated groups since there are very few protections, by design.
10. 10These 2 core roles will be in addition to existing roles in the PI website
11. 11Partners can receive funding from external sources and hold it and distribute it for PI purposes. Ideally they'll hold funds via an LLC or other incorporated entity, and ideally in a segregated bank account or crypto wallet for larger amounts.
12. 12A key principle will be that the tax-relevant control of any funds will be unambiguous at all times. While constructs like multisig wallets will be allowed, they must clearly designate who is tax-responsible and who is merely a signatory for administrative/security purposes.
13. 13The system will allow held funds to be tracked, moved and updated like a ledger but not actually hold them
14. 14Holding and moving funds, as well as keeping the BDFx tracking system synchronized with the actual money movements, is the responsibility of the people documenting it. The system should allow for, but not require, some degree of synchronization with things like bank accounts or crypto wallets in the future, but it's not an immediate priority
15. 15Partners will add funds to specific named buckets, such as for projects or a general fund etc. A bucket must indicate where the actual funds are held, eg. a specified bank account or crypto wallet. Ideally in a manner that's automatically checkable in the future (crypto will automatically qualify, bank accounts will need integrations)
16. 16Initially, funds can be moved out of a bucket only by the single owner of a bucket or an admin, but any other partner can put funds into any bucket. Later, we may allow for multiple owners of a single bucket, with n/m authority required to move funds out, while retaining unambiguous tax status. But this feature will only be allowed to be used for specific funding locations like crypto wallets or joint bank accounts that can actually embody the pattern represented by the bucket.
17. 17Partners can create named buckets and attach them to any PI project. Buckets not attached to a specific project will be considered general buckets and collectively constitute the General Fund. More than one bucket can be attached to a project, and these will collectively constitute the fund for that specific project.
18. 18Buckets may be considered equivalent to specific bank accounts or crypto wallets and we may eventually move this system onchain and/or allow for linking to bank accounts through APIs to allow for management of settlement too, but for now, this will be merely a tracking and documentation system.
19. 19Partners are also contributors so can do everything contributors can do.
20. 20Contributors can log claims for specific amounts, with justification, against any of the available project fund, or against the "General Fund." They do not see the "bucket" abstraction. They only see a list of projects and the general fund. Claims must be approved by the project owner or an admin (for the general fund) to be allowed into the payment-eligible pool.
21. 21Project owners can maintain a list of members eligible to make claims against the project, by adding them/removing them, and also set caps on how much each is allowed to bill against the project. Admins can do this for the general fund.
22. 22Funds can be added to a bucket with an "available after" date, which defaults to the date they are added.
23. 23A bucket can be in any currency or crypto asset, and this must be designated at creation. For buckets that hold assets of multiple types, creation is only allowed if embodiments are actually available (like multi-currency bank accounts or multi-token wallet)
24. 24Buckets must have clear tax jurisdictions and identified holders. So a name and country are always required.
25. 25Whenever a "settlement" action is triggered, outstanding claims are queued by seniority and paid out pro-rata against the source funds within a seniority tier according to set rules.
26. 26For project funds, the tiers are "reimbursements" and "labor." and reimbursements pay out fully before labor gets paid, pro-rata.
27. 27For the general fund, the tiers are "contractors", "reimbursements", "labor", and "management". Contractors and reimbursements pay out full against available funds before labor and management get anything. If there are funds left after contractors and reimbursements, X% is marked for labor and Y% for management, and the funds are respectively paid out pro-rata against those.
28. 28Pro-rata payments split the claims into 2 claims, paid and new claim, which gets to participate in the next round of settlement.
29. 29A "settlement" action happens when a project owner or an admin for the general fund initiates one, with a specific amount released, up to the whole available amount. The payments are then computed and the contributors (who may themselves be partners) will receive "payment vouchers" which specify how much they can claim from which named partner (which might be themselves). Once the payment is made (offline), both parties must mark the voucher as paid, and this is logged and the bucket amounts updated appropriately.
30. 30All contributors have an associated history of outstanding, claimed, and paid-out payments.
31. 31All contributors will be able to log blocks of hours against any project they're part of, or against the general fund if they're part of that. They can set a personal hourly rate in their dashboard, and maintain a log of their labor contributions in the form of hours, which are all marked "Unspecified" by default with additional options of "Volunteer, Claimed, Paid". When they make a claim, they can use their hourly rate and mark some subset of hours "claimed" and submit a legit claim using them. If the voucher eventually gets paid, those hours are marked "paid." Hours that are not claimed and paid by the end of the calendar year are automatically marked "Volunteer."
32. 32The contributor's dashboard shows total hours contributed, broken down into volunteer vs. paid. Only these 2 categories count for voting rights. Unclassified or claimed hours are not counted, until they resolve.
33. 33All contributors will have voting rights in proportion to their total contributions
34. 34Admins have authority to do anything, since this is just a tracking system
35. 35The system can generate rudimentary invoices for claims and allow claimants to enter an invoice number linking it to their own separate invoicing system. Claimants can optionally upload their own system's invoice for record-keeping.
36. 36The system can allow for upload of "proof of payment" documents such as screenshots of credit card payments, blockchain transaction records, etc.