SAFR Reporting Standard

Major version 0, spec version 0.06.

This is the canonical Reporting Standard referenced by the SAFR™ instrument. The instrument states results and commitments; this Standard holds the calculations behind them, the rules for how the numbers are produced and attested, and the governance for how the Standard itself changes. It is written to be read by a founder, an investor, an attorney, and an implementer, and to be pinned to an instrument by content hash.

This spec is the canonical, hashed artifact. It incorporates the machine-readable data schema below by reference, identified by its own content hash, so a hash of this spec transitively commits to the schema as well.

Incorporated data schema: SAFR Reporting Standard data schema, version 0.06, content hash sha256:PLACEHOLDER (placeholder, to be re-pinned in a later pass; not recomputed or validated here, TODO).

1. What this Standard computes, and the reference period

Each fiscal quarter the venture’s data flows through this Standard to produce a Quarterly Update containing Ledger Base, Expected Capacity, the venture’s Declared Budget, a single total of what the venture pays its owners and leaders, and brief commentary. Every figure is computed over the reference data period, which is the trailing twelve months ending on the most recent fiscal quarter-end (March 31, June 30, September 30, or December 31). The Quarterly Update is issued within 45 days after that quarter-end.

The Standard applies one fixed formula to every venture. None of the figures is a negotiated valuation, and none uses market comparables. This uniformity is what lets the network read one venture’s numbers against another’s and against the venture’s own history.

2. Ledger Base

Ledger Base is the venture’s standardized economic base for the instrument. It is one additive formula, applied identically to every venture, with no election: Ledger Base equals Tangible Net Assets plus the Qualified Development Asset plus Forward Revenue Value. Ledger Base is not a valuation, and it uses no market comparables. Where a bona fide priced equity round exists, that price governs; the measure sets the conversion basis only in the absence of a market price.

2.1 The components

Tangible Net Assets equals cash plus accounts receivable plus inventory plus equipment and deployed infrastructure at depreciated cost, minus all liabilities.

The Qualified Development Asset restores credit for product development that ordinary accounting expenses as it is incurred. It equals qualifying development spend at cost, amortized by vintage: each month of qualifying development spend amortizes straight-line over its own 36 months. Concretely, the asset equals the sum, over the trailing 36 months, of each month’s qualifying development spend times the greater of zero and (1 minus that month’s age in months divided by 36); spend older than 36 months contributes nothing. The asset is therefore always the trailing 36 months of spend, weighted toward the most recent: a venture that keeps investing sustains the credit, and one that stops watches it decay to zero within three years. Qualifying spend categories are defined by the schema’s tagging rules.

Forward Revenue Value values the venture’s revenue stream by stream, each stream by exactly one method, fixed by a single mechanical test so that two identical ventures resolve every stream identically. A stream is valued by the present-value method if, and only if, it is under a signed contract whose term at signing is at least 12 months. Its value is the present value, discounted at 10% per year, of its remaining contracted payments: with C the annual contracted amount and n the remaining contract term in years, the value equals C times (1 minus (1.10) to the power of negative n), divided by 0.10. Because only the remaining payments are counted, the present value glides to zero as the remaining term runs off, and it never re-counts cash a contract has already produced, which already sits in Tangible Net Assets. Every other stream is valued by a fixed quality multiple on its trailing-twelve-month revenue: 2.0 times recurring revenue, 1.0 times repeat customer revenue, and 0.25 times one-time revenue. Revenue is tagged to these three classes per the schema. The test reads two observable facts, signed status and term at signing, so a stream’s method is set at calibration and does not change quarter to quarter, and no stream is ever valued by both methods. This per-stream test absorbs the former asset-forward present value of contracted backlog as a special case: a venture whose revenue is entirely long-term contracted is valued entirely by present value, with no election and no separate basis.

2.2 Conversion price and the dilution cap

When a holder converts at the Ledger Base price, the conversion price is Ledger Base divided by the venture’s fully diluted shares, taken from the most recent Quarterly Update. Fully diluted shares means outstanding equity assuming exercise and conversion of all options, warrants, and convertible securities, including all shares reserved under equity incentive plans.

The conversion price is subject to the dilution cap, max_conversion_ownership, set at 25%. Conversion is suspended for any quarter in which converting the position’s full remaining claim under the instrument would issue shares carrying more than 25% of fully diluted equity. Because the price is Ledger Base per fully diluted share, that condition is equivalent to Ledger Base per fully diluted share standing at or below the floor the cap implies for the full remaining claim, and it also covers any quarter in which Ledger Base is zero or negative. During a suspension the Multiple continues to accrue and the redemption path is unaffected.

3. Expected Capacity and the working-capital floor

Expected Capacity is the amount the Standard computes a venture could prudently apply to redemptions in a quarter, after reserving a working-capital floor. It equals 25% of trailing-twelve-month free cash flow, floored at zero, and further limited so that cash on hand after redemptions would not fall below the working-capital floor.

The working-capital floor equals 6 months (two quarters) of trailing average monthly operating expenses.

Stated as one expression, Expected Capacity equals the greater of zero and the lesser of two quantities: 25% of the greater of zero and trailing-twelve-month free cash flow; and cash on hand minus the working-capital floor.

Expected Capacity is what the venture is measured against. The Declared Budget is the venture’s own decision for the quarter and may be any amount, including zero; when it is below Expected Capacity, the venture publishes a short written explanation. The Standard computes the expectation; the venture chooses the budget; the gap, explained or not, is the signal.

4. The owners-and-leaders total

The Quarterly Update carries a single total of what the venture pays its owners and leaders, so that money flowing to insiders is visible without exposing any individual’s pay. Owners and leaders means related parties and control persons: officers, directors, holders of 10% or more of the venture’s equity, and their immediate family and affiliated entities. The figure is the aggregate trailing-twelve-month compensation of that group, in cash and equity, reported as one number. It is never an individual breakdown. Salary is the one channel that can move value out of Expected Capacity without otherwise showing, so the Standard keeps the aggregate visible.

5. Attestation: one schema, two grades

Attestation is a layer within the single Quarterly Update, not a separate report. A Quarterly Update declares its grade, and the higher grade simply adds an independent assurance wrapper to the same numbers.

Grade one is a self-attested conforming feed: the venture’s data, mapped to this Standard, asserted by the venture and machine-readable.

Grade two adds independent third-party attestation of the Ledger Base computation, under agreed-upon procedures or an equivalent standard, recorded with the attestor’s identity, the date, the procedures applied, and a content hash of the signed attestation artifact. Grade two is required for every graduation, where an outside party is relying on the venture’s reported worth to cross a prior claim onto these rails.

Because attestation is a conditional layer of the one schema rather than a second schema, the reported shape and the attested shape can never drift apart. The data schema enforces this: when the declared grade is two, the attestation block is required; at grade one it is absent.

6. Visibility: who sees what

The Standard uses the term Visibility, not “public.” Visibility is invitational, need-to-know transparency by the venture’s standing grant. Venture Visibility is an invitation, not a listing.

The Visibility tier carries aggregate figures: the venture’s standardized economic base, capacity figures, revenue mix, and a size band. The venture shares this with invited network participants.

The Holder tier carries everything in the Visibility tier plus the owners-and-leaders total and the full Quarterly Update, delivered to each holder, together with the attestation wrapper when present.

No tier ever includes personally identifiable information, customer or counterparty identities, partner names, or pipeline detail. The underlying ledger itself is not distributed through the Standard; only schema-shaped outputs are, and only by the venture’s standing grant. What a venture chooses to circulate elsewhere, such as for a Regulation CF raise or an acquirer’s diligence, is its own affair and outside this Standard.

7. Conformance: how the numbers are actually produced

Initial conformance is set by a human Certified Business Analyst, who calibrates each venture’s data mapping to this Standard and sets a high baseline for what conforms. SmartTrustee then applies the same weights to the same data, conforming to this Standard, so the automated computation matches the calibrated baseline rather than diverging from it. The method is expected to refine as volume accumulates, and those refinements ship as minor versions under the governance below. This is the reason the instrument incorporates the Standard by reference rather than freezing the formulas in its own text: the result is stable, the method matures.

8. Versioning and governance

The Standard uses semantic versioning, written MAJOR.MINOR, within a pinned major version.

Minor versions are refinements: calibration improvements, additional revenue-quality tags, better data-source mappings, and tightening of the conformance method as the network teaches the Standard. Minor versions apply automatically to outstanding instruments, because by definition they do not change the deal.

A major version is any change that would alter a previously issued position’s computed Ledger Base or Expected Capacity, for any quarter, by more than 3%. A major version applies to an outstanding instrument only with the holder’s and the venture’s consent. The 3% threshold is what makes the boundary objective rather than a matter of the maintainer’s discretion: a change that moves a real position’s quarterly figure by more than 3% is, by definition, a new deal that must be agreed to, and anything smaller is a refinement already accepted at issuance.

Each executed SAFR pins the major version and records the content hash of this spec in effect at issuance. The pin establishes exactly what the rules were on the day the instrument was signed, while the major-version mechanism gives the Standard room to improve without re-papering every outstanding instrument.

Release note for this revision (not a standing rule). The move to per-vintage development amortization in this revision is a change that would alter a previously issued position’s computed figure by more than the 3% threshold, so on an outstanding instrument it would require the holder’s and the venture’s consent. Pre-launch there are no outstanding instruments, so no consent is required and small spec increments apply until launch. The major-version designation is unchanged. This note is specific to the per-vintage amortization change in this revision and is not carried forward verbatim into later versions.

Governance of the Standard is open: proposed changes, a comment window, and published release notes, so the Standard demonstrably belongs to no single vendor.

9. The data schema

The machine-readable data schema, incorporated by reference and identified by the content hash at the top of this spec, defines the exact shape of a conforming Quarterly Update: the required fields, their tier routing for Visibility and Holder distribution, the conditional attestation rule, the canonical constants mirrored for machine use, and the exclusion list that keeps identities and the raw ledger out of every tier. An implementer builds to the schema; this spec governs what the fields mean and how the figures are computed.

Notice

This is an open canonical Standard, major version 0, spec version 0.06, provided without warranty and without legal advice. It is free to use under its open license and is pinned to instruments by content hash. The SAFR™ name is reserved for unmodified canonical instrument terms maintained on a conforming feed pinned to a published version of this Standard.