Skip to content

Preview · not officially published. Technical information only; the planned DLT is not live.

ByteShares.org

Layers

Governance Layer

Documented architecture

The technical governance layer describes how decisions would be represented as protocol data. It is not the cooperative's governance, and it does not carry any binding decision today.

Source / verification
Owner-asserted canon; governance documents not supplied
Document version
Not yet assigned
Last reviewed
19 September 2026

Not cooperative governance

Member governance — general meetings, member votes, the board and any legally binding decision — sits with the ByteShares.dk cooperative. It is not conducted here and is not mirrored here.

What this layer describes is narrower: how a decision, once made, could be expressed in a machine-readable form that other layers can reference.

Objects as documented

  • Proposal — a described change, its rationale and the state it would produce.
  • Role — a named capability held by a participant, granted and withdrawn explicitly.
  • Threshold — the condition a proposal must satisfy before it is treated as accepted.
  • Record — the immutable outcome entry, including who was eligible and what was decided.

Authority architecture

Constitutional authority

Documented architecture

Defines the highest-order mandate, reserved powers and boundaries that subordinate decisions must not exceed.

Board / committee authority

Documented architecture

Expresses delegated mandates, scopes, terms and thresholds for accountable institutional decision-making.

Protocol authority

Documented architecture

Converts an authorized outcome into machine-verifiable permissions and rule changes without creating legal authority by itself.

Technical governance flow

  1. 01

    Proposal

    A change is described with its rationale, its scope and the state it would produce.

  2. 02

    Decision

    Where a vote applies, eligibility and threshold are fixed before the decision is taken, not after.

  3. 03

    Authorization

    The outcome becomes an explicit authority record naming scope, holder, rule version and validity.

  4. 04

    Execution

    The protocol applies the authorized rule version. Execution never invents authority it was not given.

  5. 05

    Evidence

    A proof object records the inputs, the authority relied on and the outcome.

  6. 06

    Anchoring and closure

    Evidence is anchored, and the epoch closes with a snapshot fixing the resulting state.

The flow is a written design. No stage is implemented, and no decision taken anywhere is currently carried by it.

Governance sequence

Documented architecture

  1. 01

    PreDAO

    Preparatory governance state in which scope, authority and eligible participants are defined.

  2. 02

    Genesis Memo

    The initial authorized statement of rules, roles, boundaries and starting state.

  3. 03

    Memo Anchoring

    A hash, timestamp and reference bind the approved memo to the protocol record.

  4. 04

    Epoch Closure

    The period closes with a defined state, governance outcomes and proof snapshot.

Exceptions, reversals & disputes

Exception governance

Planned

Exceptional action should require a named authority, narrow scope, reason, expiry and permanent audit record.

Reversal & dispute pathways

Planned

A disputed result should be stayed, reviewed and resolved through an authorized compensating decision. Prior history remains visible rather than being deleted.

No exception body, reversal procedure, dispute forum or response timetable is operating.

Current state

Voting implementation
None
Role registry
Not created
Binding force
None — descriptive only
Legal review
Not started
Proof and execution layerCoverage registry

Evidence register

Each statement on this page is tracked against a source. A claim without a verified source is never presented as fact.

Claims on this page and the verification state of their sources
ClaimSource typeVerificationNote
Authority domains, governance objects and epoch sequenceMaster Business Plan v2.1 / aligned canonSource claimed, not yet verifiedOwner-asserted; the cited document has not been supplied for inspection and no protocol implementation exists.
Exception, reversal and dispute pathwaysOwner-provided aligned technical canonSource claimed, not yet verifiedPathways are owner-asserted; procedures, responsible bodies and timetables remain undefined.
Relationship to cooperative statutesByteShares.dk statutesSource claimed, not yet verifiedStatutes govern member decisions; alignment not yet reviewed.