v0-pre-alphaSep 13, 2025
Pre-alpha educational framework. Not legal, tax, accounting, investment, employment, or financial advice. Fairly Exact v0 assumes an LLC-based implementation, but governing documents, interest design, tax treatment, filings, and compliance must be determined by qualified professionals before use.

Dynamic Equity and Voting

How the member ledger, configurable voting thresholds, departures, and finalization work during the dynamic period.

The Member Ledger

The member ledger is Fairly Exact’s allocation and governance record. It contains only units minted by accepted Contribution Blocks. Funding Blocks, Advisor Blocks, reimbursements, and other obligations remain outside it and connect to separately prepared instruments.

The ledger’s legal effect depends entirely on governing documents and procedures prepared or approved for the specific company. The framework and software calculate and record allocations; they do not create an entity, admit a member, issue an interest, authorize a vote, or authorize a distribution.

Joining and the Dynamic Period

A contributor begins at zero accepted units only after the admission, intellectual-property, and professional-review steps required for that company have been completed and recorded.

Contribution Blocks follow one lifecycle: open → activate → deliver → accept. Acceptance mints the approved allocation into the member ledger and marks the block MINTED. A block that is not delivered or accepted receives a zero allocation. “Forfeiture” is reserved for an expressly documented misconduct remedy.

The framework does not authorize discretionary distributions during the dynamic period. A contemplated discretionary distribution triggers finalization first. Qualified professionals must design any tax distributions, allocations, or exceptions in the governing documents.

Ledger-Weighted Voting

Each voting matter stores its own approval threshold. The default threshold is more than 50% of all eligible voting units; governing documents may specify a different threshold.

For each matter:

  1. Establish the record date and eligible voting units under the governing documents.
  2. Include active contributors’ accepted, undisputed member-ledger units. Exclude departed contributors, disputed units, Funding Blocks, and Advisor Blocks.
  3. Let each authenticated eligible voter cast only their own ballot; count missing ballots as abstentions.
  4. Return APPROVED when FOR exceeds the configured approval threshold.
  5. Return REJECTED when AGAINST exceeds the configured approval threshold.
  6. Return STATUS_QUO when neither side exceeds the threshold, including ties and abstention-driven non-decisions.

Fairly Exact saves the threshold, eligible-ledger snapshot, ballots, tally, and result. The framework records the calculation; governing documents determine whether and how it has legal effect.

Bound Matters

A voting matter may be bound to the state change it decides. A bound matter records the transition it proposes, and the transition happens when the matter passes — not as a separate act afterwards. Nothing is bound by default; each company chooses which transitions it gates.

The transitions that can be bound are block activation, block acceptance, a stage change, a contributor’s admission, the conversion of a member’s cash balance into a Funding Block, approval of a specific revision of a Funding Block’s proposed terms, a change to the organization’s team-set terms (unit rate, Funding Block minimum, downside split, conversion share total and review cycle), and a change to the governance policy itself. A block acceptance matter carries the exact final split it would mint, so what is approved is the number rather than the intention.

An approved matter that cannot be carried out — because the block already moved, or the stage already changed — does not close. Recording a matter as approved while its transition never happened would leave the ledger asserting something untrue for as long as the record survives.

A matter that is rejected, or that ends in status quo, changes nothing. Its subject stays where it was and another matter may be opened on it.

The Governance Policy

The governance policy states, for each transition, whether it requires a passing matter and what threshold that matter must exceed. It is the ledger’s mirror of the operating agreement, and it should be set to match what the governing documents actually require.

The default threshold is a majority of eligible voting units. Approving a Funding Block’s terms defaults to a two-thirds supermajority: it commits every member to a financing negotiation, but a single small holder should not be able to block it.

Amending the policy is itself a voting matter, judged under the policy already in force. A matter proposing a lower threshold is decided at the threshold that existed when the matter opened. This is the same rule an operating agreement applies to its own amendment, and without it the gate would be circular: a bare majority could lower the bar it had just failed to clear.

The framework sets no floor. A company whose members approve removing a gate has removed it, including the gate on removing gates. The framework records what was decided; it does not overrule the people deciding.

Founding Acts

A matter cannot open voting until at least one active contributor holds accepted, undisputed units, because there would be no eligible voting units to snapshot. Units come only from accepted Contribution Blocks. A company that gated its first block would therefore never mint anything.

Until the ledger has minted any units, a gated transition is recorded directly and marked as a founding act. In practice this covers a company’s first block: accepting it is what permanently ends the window. If a mature ledger later has no eligible voters because its unit holders departed or their units are disputed, the founding window does not reopen; the company must use the recovery process in its governing documents. Every record taken during the true founding window says so, so the absence of a vote is visible on the record rather than inferred from its absence.

Departure Before Finalization

A departed contributor retains the balance of accepted units shown in the member ledger. Later accepted Contribution Blocks may change that balance’s percentage of the total.

Departed contributors are excluded from interim voting calculations. Pending work still follows the normal delivery and acceptance process. The governing documents and qualified professionals must determine the legal, tax, economic, and administrative consequences of departure; the framework does not supply those conclusions.

Mandatory Finalization

The ledger freezes and finalization begins at the earliest documented trigger, which may include:

  • a priced financing;
  • an acquisition, merger, dissolution, or other liquidity event;
  • sustainable ability to pay market compensation;
  • a material capital or allocation change that should not continue under the dynamic method;
  • a contemplated discretionary distribution; or
  • a declaration approved using the configured approval threshold.

Before finalization, resolve pending and disputed Contribution Blocks under the documented acceptance process. Then calculate path-neutral frozen percentages from all accepted Contribution units, including accepted units held by departed contributors.

The team then selects FIXED_LLC or CORPORATE_CONVERSION. Either path requires professional execution. See Freeze and Finalization for the distinct requirements.

Operational Controls

Maintain a clear audit trail for contributor admission, IP assignment, professional review, each block lifecycle event, acceptance, allocations, votes, departures, and finalization.

Reconcile the member ledger regularly, preserve immutable voting snapshots, and test entry, departure, disputes, abstentions, ties, and both finalization paths before adoption and after rule changes. Reconcile the cash ledger and separate instruments independently; never include them in member-ledger calculations.

The operating method is designed to be simple. Its implementation is not legally self-executing.