Concepts
Governance
Organizational chains carrying membership, roles, ownership, treasury and authenticated voting for parties that will not hand each other the keys.
Coordination without a custodian
Several independent parties need to run something jointly — a shared network, a funded program, a joint venture — and none of them will accept another holding the keys. UniNet treats that as an infrastructure problem rather than a legal one: an organization is a chain of its own, holding its membership, its roles, its assets and its decision record in state that every party can read and no single party can edit alone.
Why a multisig is not sufficient
A multisig answers one question: how many signatures are needed to move the money. That is the treasury, and the treasury is the easy part.
| Question | Multisig | Organizational chain | | --- | --- | --- | | Who may move funds | n-of-m over a fixed list of keys | An authority derived from a role, referencing the decision that granted it | | Who is a member | Not represented; the key list stands in for it | An explicit entry: identity, role, scope, term | | What roles exist | None; every signer is equivalent | Roles separate proposing, voting, spending and admitting | | Who may sign what next quarter | Changed by editing the key list out of band | Changed by a governed operation, recorded | | What a decision actually was | A thread, a document, a call | A proposal and its tally | | Whether a transfer was authorized | Inferred from who signed it | The transfer refers to the decision |
The underlying problem is that a signer list is a membership model flattened into a set of keys. Once flattened, everything about how the group works — who may join, who may put a question, what a departing member loses access to — lives outside the system, in documents the chain cannot read. When the parties disagree, they are arguing about a document rather than reading a state.
What an organizational chain holds
Organization
│
├── membership identity → role, scope, term
├── roles what a member may propose, vote on, sign
├── ownership what the organization holds, as the organization
├── treasury a balance held by the organization, not by an officer
└── record proposals, ballots, tallies, amendments
Every member keeps its own keys. Membership is a link between an identity the member already controls and a role the organization defines, so participation does not require handing custody to anyone. Admission and removal are operations the organization's own rules govern, which means the membership model and the decision model are the same machinery rather than a document describing a key list.
Authenticated voting
A ballot is signed by the member identity casting it. Weight is drawn from membership as recorded when the proposal opened, so the electorate for a decision is fixed at the moment the decision starts rather than reconstructed afterwards. The tally is recomputable from recorded state by anyone with read access: a party unhappy with an outcome can recompute it instead of disputing whoever kept the minutes.
Amendments run the same way. Changing the voting rule is a proposal decided under the voting rule currently in force, and the change is recorded alongside every decision made before it.
Governance models as configuration
Consortiums, nonprofits, companies and hybrids of them do not need different primitives. They differ in how a small number of dimensions are set.
| Dimension | What it decides | | --- | --- | | Admission | Who may become a member, and who decides that | | Weighting | One identity one vote, share-weighted, role-weighted, or a combination | | Proposal rights | Which roles may put a question to the organization | | Treasury authority | Which decisions release funds, and up to what ceiling | | Amendment rule | What it takes to change any of the above |
A consortium of competing companies typically sets admission by unanimity and weighting flat. A nonprofit with a member assembly sets admission open and weighting flat. A company sets weighting by ownership. A hybrid mixes them by role. Expressing the model as configuration of state, rather than as a bespoke contract per organization type, is what lets an organization change shape over its life without migrating to a different system.
How it composes with the other primitives
Membership entries reference identity, so a member is the same entity here as it is everywhere else on the network. Roles are delegated authority with the organization as grantor, which means removing a member revokes what was derived from that membership by the same cascade as any other revocation. The treasury is the wallet primitive described in assets and payments, held by the organization rather than by an individual, so a treasury payment is an ordinary signed transfer whose authority happens to come from a role. None of this is a governance product attached to the side of the network.
Where this sits relative to the rest of UniNet
This is the least finished part of the network, by a clear margin. The surfaces an evaluator reaches for first — creating an organization, adding and removing members, running a vote, reading its result — are precisely the ones that do not exist in finished form today; parts of them are placeholder or mocked. Read this page as a model to review and argue with, and keep real decisions and real funds on whatever you use now. The status block on this page carries the formal statement.
What is not finished
Significant parts of the external autonomous-organization interface remain placeholder or mocked. Do not migrate a live treasury or a live vote onto this.
Parts of smart-contract execution are incomplete.