Explore

Module 4: Treasury & Capital Structure

Asset Classification, Capital Allocation Logic, & Treasury Custody

Institutional continuity requires formalized capital coordination. This module defines how value enters, is classified, allocated, safeguarded, and recirculated within the governance system. Capital governance establishes the authority boundaries under which resources are stewarded. It formalizes asset classification, authorization tiers, reserve policies, allocation pathways, and review mechanisms. Resource flows are aligned with constitutional constraints and decision thresholds.

This module governs:

Capital classification across financial and non-financial forms

Authorization structures and mandate-bound expenditure

Allocation procedures linked to decision systems

Reserve and solvency safeguards

Recirculation and reinvestment logic

Reporting and audit requirements

Treasury structure determines how authority over resources is exercised, constrained, and reviewed over time. Capital flows must remain traceable, proportionate to mandate scope, and protected against concentration or misallocation. Treasury custody integrates with the accountability ledger, decision systems, and incentive structures to preserve institutional coherence.

⁠

1. Resource Classification

Capital categories are differentiated to prevent ambiguity, commingling, and mandate drift:

Operational Capital: Resources required for ongoing coordination, infrastructure, and administrative continuity.

Programmatic Capital: Resources allocated to defined initiatives or strategic priorities.

Reserve Capital: Funds retained for continuity, risk mitigation, and systemic resilience

Market Capital: deployed in or derived from external markets, including equity, tokenized instruments, or tradable financial assets. Managed under defined exposure, liquidity, and volatility constraints

Philanthropic Capital — Purpose-restricted capital contributed for mission-aligned activities under defined usage constraints. Subject to donor terms, reporting requirements, and segregation from discretionary treasury funds.

Reinvestment Pool: Allocations designated for strengthening shared infrastructure and long-term capacity.

Classification establishes mandate clarity and preserves allocation integrity.

⁠

2. Capital Inflow Pathways

The treasury defines legitimate sources of value, including:

Membership or participation contributions

Grants and external funding

Revenue-generating activities

Impact-aligned investments

Tokenized or decentralized capital mechanisms (if applicable)

All inflows must comply with constitutional constraints, decision authority, and declared treasury policies.

⁠

3. Allocation Mechanisms

Capital deployment follows formally defined and auditable pathways:

Proposal-based funding through governance processes

Delegated budget authority within mandate scope

Formula-based distribution models

Milestone-based disbursement schedules

Allocation logic must be transparent, attributable to decision authority, and recorded in the accountability ledger.

⁠

4. Circulation & Reinvestment Logic

Treasury custody may encode structured capital circulation, including:

Defined reinvestment ratios

Surplus allocation rules

Capacity-strengthening allocations

Risk-adjusted deployment policies

Capital circulation is calibrated to preserve continuity and institutional resilience rather than accumulate static reserves without mandate alignment.

⁠

5. Treasury Custody & Risk Safeguards

The system defines formal custodial and risk constraints:

Multi-signature or distributed authorization protocols

Spending thresholds requiring elevated approval

Segregation of financial duties

Independent oversight or audit roles

Exposure and liquidity parameters

Stratified authorization and custody controls reduce concentration risk and protect fiduciary integrity.

⁠

6. Transparency & Reporting

Treasury activity is systematically recorded and disclosed through:

Periodic financial reporting

Allocation histories

Budget tracking dashboards

Performance and impact summaries

Financial transparency preserves institutional legitimacy and auditability.

⁠

7. Financial Review & Adaptation

Treasury governance includes periodic review cycles for:

Budget recalibration

Reserve adequacy assessment

Allocation performance evaluation

Risk exposure monitoring

Financial structures may evolve through defined review pathways without destabilizing governance continuity.

⁠

Structural Function

This module formalizes resource coordination as a governance function. It ensures:

Purpose-aligned capital deployment

Distributed authorization

Transparent and traceable allocation

Risk-calibrated stewardship

Long-term institutional viability

Treasury functions as an active custodial and allocation system, not a passive holding mechanism.

⁠

Module 4: Treasury & Capital Structure Ai Implementation Guide

Purpose

Compile treasury governance into deterministic financial logic. Enforce capital classification, custodial authority tiers, allocation constraints, reserve safeguards, and auditable transaction lineage at the system level. The treasury layer must operate as a rule-bound execution environment governed by constitutional constraints and decision authority.

Capital Classification Schema

The system must support a configurable and extensible capital ontology.

CapitalCategory { id: UUID name: string classification: operational | programmatic | reserve | reinvestment | market_exposed | restricted mandate_scope: text allocation_constraints: object reporting_obligations: object liquidity_parameters: object risk_profile: low | moderate | high governance_linkage: decision_class_reference }

Requirements:

Every inflow and disbursement must reference a CapitalCategory.

Restricted categories must enforce mandate-bound allocation constraints.

Market-exposed categories must enforce exposure and liquidity parameters.

Reserve categories must enforce minimum ratio safeguards.

Classification is mandatory and immutable per transaction record.

Treasury Custody Model

Minimum system entities:

treasury_accounts

capital_categories

capital_sources

inflow_records

allocation_records

disbursement_records

reserve_monitoring

custody_policies

authorization_matrix

audit_logs

Each treasury account must define:

TreasuryAccount { id capital_category_reference custody_model: single_sig | multi_sig | contract_controlled authorization_tier spending_threshold escalation_threshold reserve_exempt: boolean }

Custody policies must be parameterized per instance.

Capital Inflow Logic

System must:

Record inflow source type (donation, grant, revenue, investment, token issuance, etc.)

Validate compliance with constitutional and treasury policy

Assign classification at entry

Timestamp and immutably log transaction

Attach documentation reference

Optionally verify on-chain settlement if applicable

Restricted inflows must require designation mapping before acceptance.

Allocation & Authorization Engine

All allocations must pass deterministic gating:

Proposal reference (if governance-driven)

Delegated authority verification

Threshold validation

Category constraint validation

Reserve impact simulation

Authorization tier validation

Workflows states: allocation_requested authorization_pending approved executed rejected flagged

Each allocation must generate:

Governance approval reference

Execution confirmation record

Linked documentation

Ledger trace linkage

Milestone-based disbursement must support conditional release triggers.

Custody & Authorization Controls

The system must enforce:

Segregation of proposal, approval, and execution roles

Multi-signature enforcement where required

Tiered spending caps

Escalation triggers above defined thresholds

Emergency freeze capability (if constitutionally defined)

All custody actions must generate immutable audit records.

No allocation may bypass authorization logic.

Reserve & Risk Enforcement

System must support:

ReservePolicy { minimum_reserve_ratio liquidity_floor exposure_limit_percentage concentration_cap volatility_buffer (for market_exposed capital) } Automated monitoring must:

Calculate operational reserve ratio

Flag liquidity breaches

Trigger exposure alerts

Prevent allocations violating reserve thresholds (if configured)

Optional advanced layer:

Scenario simulation engine

Stress-testing models

Transparency & Oversight Interface

Dashboard must display:

Capital balances by classification

Reserve ratios

Allocation pipeline status

Historical inflow/outflow trends

Exposure concentration metrics

Restricted fund utilization compliance

Oversight roles receive read-only access to custody and allocation records.

Reporting & Audit Interface

Treasury module must support:

Category-level reporting

Mandate compliance reporting (restricted funds)

Solvency summaries

Exposure breakdown reports

CSV / API export

Audit-ready ledger output

Version-linked configuration traceability

All reports must reconcile with accountability ledger records.

Structural Constraints

Treasury execution logic must remain:

Constitution-aware

Role-aware

Threshold-bound

Category-constrained

Custody-enforced

Fully auditable

Governance determines authorization.

Treasury enforces execution within defined parameters.

Oversight analytics operate as a separate intelligence layer.

This version:

Integrates market-exposed and restricted capital

Clarifies custody vs allocation

Strengthens determinism

Separates governance from execution

Maintains modular extensibility

Aligns with federation-ready architecture

Treasury State Machine

A deterministic lifecycle for capital intake, custody, allocation, disbursement, reconciliation, and exception handling.

Core Objects

TreasuryTransaction (applies to inflows, allocations, disbursements, internal transfers)

tx_id

capital_category_id

account_id

amount, asset_type

initiator_actor_id

authority_basis: proposal_ref | delegated_authority_ref | emergency_ref

authorization_tier

supporting_docs[]

risk_snapshot_ref

ledger_refs[]

state

timestamps{}

Treasury Transaction States

Baseline lifecycle states

intake_pending

classified

policy_check_pending

policy_check_failed (terminal unless remediated)

authorization_pending

authorization_failed (terminal unless remediated)

ready_to_execute

execution_in_progress

executed

reconciled (terminal)

flagged (non-terminal exception state)

cancelled (terminal)

Protective overlay states (can supersede the baseline flow)

frozen (blocks execution; allows review/audit steps only)

holdback_required (execution allowed only after additional condition is satisfied)

State Transitions

A. Inflow path

intake_pending → classified

Trigger: source recorded + category assigned

classified → policy_check_pending

Trigger: documentation + compliance flags attached

policy_check_pending → authorization_pending

Condition: policy pass (restricted fund rules, jurisdiction rules, sanctions/flags)

authorization_pending → ready_to_execute

Condition: custody rules satisfied (multisig/role approvals)

ready_to_execute → execution_in_progress → executed

Trigger: settlement initiated; then confirmed (bank/on-chain/off-chain)

executed → reconciled

Condition: ledger write + balance reconciliation + reporting hooks emitted

Failure edges:

policy_check_pending → policy_check_failed

authorization_pending → authorization_failed

B. Allocation/disbursement path

intake_pending → classified (allocation request created with category + account)

classified → policy_check_pending

Includes: reserve impact check, mandate scope check

policy_check_pending → authorization_pending

Condition: decision authority verified (proposal outcome or delegated mandate)

authorization_pending → ready_to_execute

Condition: approvals meet threshold tier

ready_to_execute → execution_in_progress → executed → reconciled

C. Transfers/adjustments

intake_pending → classified → policy_check_pending → authorization_pending → ready_to_execute → executed → reconciled

(same gating; transfers must validate both source and destination categories/accounts)

Exception Handling Logic

Flagging (non-terminal):

Any state may transition to flagged when:

category mismatch detected

documentation missing / inconsistent

reserve ratio breach predicted

concentration/exposure limit breached

authority basis invalid or stale

duplicate tx pattern / anomaly detection triggers

From flagged, only these transitions are allowed:

flagged → policy_check_pending (after remediation)

flagged → authorization_pending (if policy already passed; re-auth required)

flagged → cancelled (if voided)

Freeze overlay:

Any non-terminal state may transition to frozen when:

emergency protective action invoked

audit event requires custody halt

systemic risk threshold exceeded

From frozen, only:

frozen → flagged (triage pathway)

frozen → authorization_pending (explicit unfreeze authorization)

frozen → cancelled

Deterministic Guards

Guards are evaluated at every transition into authorization_pending, ready_to_execute, and executed.

G1 — Category integrity

capital_category_id must be set and immutable after classified.

G2 — Authority validity

One of:

ratified proposal reference (binding)

valid delegated mandate reference (within scope, within expiry)

emergency reference (time-bounded; requires post-action review scheduling)

G3 — Custody satisfaction

Custody model requirements satisfied (multisig quorum, role approvals, tier gating).

G4 — Reserve protection

If category impacts reserve constraints, execution must be blocked when minimum ratios would be violated.

G5 — Exposure limits (market-exposed categories only)

Concentration and exposure caps must pass pre-execution.

G6 — Ledger finality

No transition to reconciled without immutable ledger reference + balance reconciliation event.

Post-Action Review Hooks

Automatic review events must be scheduled on:

any emergency_ref execution

any freeze/unfreeze action

any reserve breach attempt

repeated anomaly flags within a defined time window

These hooks emit ledger events and open a review record linked to the transaction lineage.

Minimal State Machine Spec Block

{ “treasury_state_machine”: { “states”: [ “intake_pending”,“classified”,“policy_check_pending”,“policy_check_failed”, “authorization_pending”,“authorization_failed”,“ready_to_execute”, “execution_in_progress”,“executed”,“reconciled”,“flagged”,“cancelled”, “frozen”,“holdback_required” ], “terminal_states”: [“policy_check_failed”,“authorization_failed”,“reconciled”,“cancelled”], “guards”: [“G1_category_integrity”,“G2_authority_validity”,“G3_custody_satisfaction”,“G4_reserve_protection”,“G5_exposure_limits”,“G6_ledger_finality”], “overlays”: [“frozen”,“holdback_required”] } }

Treasury Health State Model

A system-level state machine (separate from transaction state) that tightens custody/authorization rules based on solvency, exposure, and operational stress.

⁠

1. Purpose

The Treasury Health State is a deterministic supervisory layer that:

gates or tightens authorization tiers and spending thresholds

triggers protective actions (e.g., freezes, holdbacks)

emits health telemetry for oversight and audit continuity

remains independent of any specific ledger or custody stack

This state machine evaluates aggregate treasury conditions and applies policy overrides to transaction execution.

⁠

2. Health States

stable

Normal operation. Default thresholds and custody requirements apply.

watch

Early risk signals. Increased scrutiny for mid/high-tier transactions; additional reporting cadence.

constrained

Material stress. Non-essential disbursements throttled; higher approval thresholds; reserve protection hard-gated.

critical

Emergency posture. Execution halted except predefined essential flows; treasury freeze controls available; post-action ratification required for any exception.

(Optional) recovery

A time-bounded state after critical where limits are relaxed only after passing remediation checks.

⁠

3. Health Inputs

Health evaluation is computed from a fixed set of metrics (instance-configurable thresholds):

Reserve ratio: operational_reserves / projected_obligations

Liquidity coverage: liquid assets / short-term outflows

Exposure concentration: top-N holders, top-N counterparties, asset concentration

Volatility exposure: percent of treasury in market-sensitive assets

Runway: months of operations at current burn

Disbursement pressure: pending obligations vs available liquid capital

Anomaly index: flagged/failed tx rate, repeated exceptions, abnormal flow patterns

Custody risk: signer availability, multisig quorum reliability, key rotation status

⁠

4. State Transition Rules (Deterministic)

Transitions are triggered by thresholds and sustained-duration conditions (to avoid oscillation).

Stable → Watch if any are true:

reserve ratio falls below watch_reserve_min

anomaly index exceeds watch_anomaly_max

exposure concentration exceeds watch_concentration_max

Watch → Constrained if any are true:

reserve ratio falls below constrained_reserve_min

liquidity coverage below constrained_liquidity_min

repeated critical anomaly triggers within a defined window

Constrained → Critical if any are true:

reserve ratio below critical_reserve_min

liquidity coverage below critical_liquidity_min

custody risk breach (e.g., signer quorum unreliable)

confirmed material loss / compromise event

Recovery / De-escalation

De-escalation requires both metric recovery and stabilization time:

critical → recovery only after protective action review record exists + minimum metrics restored

recovery → constrained → watch → stable requires:

all metrics above state minima

sustained for n consecutive evaluation intervals

no new critical anomaly flags

⁠

5. Policy Overrides Per State

Stable

default tier thresholds

normal reporting cadence

Watch

require additional approval for transactions above watch_amount_threshold

increased reporting cadence (e.g., weekly)

stricter anomaly handling (auto-flag)

Constrained

elevate approval thresholds one tier (e.g., 1-of-3 → 2-of-3)

enforce holdbacks for non-essential categories

block disbursements that reduce reserve ratio below constrained minima

mandatory risk note + documentation for any allocation

Critical

freeze all non-essential transactions

allow only essential_allowlist categories/accounts

emergency execution requires explicit emergency authority basis + automatic post-action review

initiate custody verification / signer check protocol

{ "treasury_health_state": { "states": ["stable", "watch", "constrained", "critical", "recovery"], "evaluation_cadence": "daily", "metrics": [ "reserve_ratio", "liquidity_coverage", "exposure_concentration", "volatility_exposure", "runway_months", "disbursement_pressure", "anomaly_index", "custody_risk" ], "overrides": { "watch": { "approval_tier_bump": 0, "auto_flag_over_amount": true }, "constrained": { "approval_tier_bump": 1, "holdback_non_essential": true }, "critical": { "freeze_non_essential": true, "essential_allowlist_required": true } } } }

7. Where This Lives in the Architecture

Module 4 (Treasury & Capital Structure) defines the state machine, thresholds, and override policies.

Accountability Ledger records every state transition, trigger metrics snapshot, and override applied.

Decision Systems / Emergency protocol supplies the authority basis for exceptions during critical.

If you want the next step, the clean add-on is a Treasury Essential Allowlist Spec (what counts as essential; who can modify it; and the emergency ratification requirements).

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.