AStarted by AXIS Editorial
The platform's most-referenced and least-explained artifact, explained. Every other thread in this forum eventually points at "verified revenue history" — this one walks through what the Trust Fabric Passport actually is, what "proof-of-life" means mechanically, and what a buyer would do with it in diligence.
The problem it exists to solve, stated as buyers experience it
Small-app diligence has a verification floor problem: revenue claims arrive as screenshots and CSV exports, both trivially fabricated; even genuine dashboard walkthroughs prove a moment, not a history. Buyers compensate the only way available — discounting claims and expanding diligence (reconciled bank statements, processor-login-over-shoulder sessions, escrowed verification periods) — which taxes every honest seller with the fraud premium of the dishonest ones. The M&A education line this platform started from ("buyers ask for reconciled bank statements because Stripe screenshots are trivially faked") describes the floor; the Passport is the attempt to raise it.
What the Passport is, mechanically
When an app connects PAID, every subsequent transaction — charge, refund, churn event — is recorded on the PAID side as it happens, outside the seller's editorial control. The Passport is the queryable evidence artifact over that record: a verified, dated transaction history whose integrity claim rests on where it lives (the payment rail itself, held by a party who isn't the seller) rather than on the seller's presentation of it. "Proof-of-life" is the operative property: the history demonstrates continuously that real customers made real payments at real timestamps — the revenue equivalent of a heartbeat monitor versus a photograph of a pulse.
What it is not — the honest boundaries
Not retroactive (history begins at connection — the connect-early argument every thread makes); not a full financial picture (it evidences the PAID-processed revenue stream, not expenses, not off-rail revenue — the diligence-checklist thread covers what it doesn't replace); not a valuation (evidence of revenue, not opinion of worth — Rule 7 of the Community Guidelines applies: guidance, never advice); and not automatic access (the seller authorizes each disclosure — buyers see it when and because you decide, and on /acquire the full data room comes only after the NDA and qualification step).
What a buyer can do with it, stage by stage
Public-listing stage: sees the PAID Verified badge and the verified-period dates — enough to know checkable history exists, which is itself a filter. Data-room stage: with your authorization, reads the transaction-level history — volume and trend, refund rates, churn events, customer-count trajectory — and runs the analyses the revenue-quality thread describes (cohort retention, concentration, seasonality) against data, not exports. Closing stage: the Passport period cross-checks the conventional documents (bank statements, tax filings) — discrepancies between verified rail and claimed totals become the diligence conversation, in whichever direction they point.
The intended effect: verification is there to shorten diligence (analysis of a checkable record in place of weeks of trust-building), and a verified history is the first item on the 3-5x thread's what-moves-you-toward-5 list. The asymmetry the whole platform is built on: the cost of the artifact is connecting early and routing real revenue through it — after which the proof accrues while you sleep.
Questions this walkthrough didn't answer can start a new thread on GitHub Discussions (the link is at the foot of this page) — this thread is the standing reference, and it improves by being interrogated. What would you need the Passport to show before you'd trust it as a buyer?
Follow-up question, from the buyer's side: "What stops a seller from manufacturing transactions — friends' cards on subscriptions for a year? Verified-fake is scarier than unverified-real."
The honest answer: nothing prevents it, and the Passport's design assumes sophisticated buyers will check for it — what verification changes is that manufactured revenue must be performed continuously on the real rail, which makes it expensive (real money, real processing costs, months of commitment) and, more importantly, pattern-visible: transaction-level history exposes exactly the signatures fabrication struggles to fake — customer-count-to-volume ratios, payment-method diversity, churn behavior (manufactured cohorts don't churn like real ones), refund patterns, and geographic/timing distributions. Buyer diligence on a Passport should include those pattern reads (the revenue-quality thread's cohort analysis doubles as fraud analysis), plus the closing-stage cross-checks against bank reality. Verified doesn't mean trust-blindly; it means the fraud now has to beat forensics instead of beating a screenshot — a materially higher bar, priced accordingly.
Follow-up question: "My revenue is split — 60% through PAID since I connected, 40% on legacy Stripe subscriptions I can't migrate without churn risk. How does a partial Passport read in diligence?"
Better than intuition suggests, if presented with the split explicit: the verified 60% anchors trust for the whole story — a buyer can check the Passport stream directly, then has grounds to extend credence to the documented-conventionally 40% (Stripe exports plus bank reconciliation, the standard evidence), because a seller whose checkable claims check out earns the benefit of the doubt on the rest (the funnel-candor mechanism from the traction thread, at diligence scale). Presentation discipline: state the split and its reason upfront (migration-churn caution is a reason buyers respect — it's revenue protection), reconcile the two streams to one total against bank statements, and let new subscriptions accrue to the verified rail so the split trends toward verified over time — a trendline you can show. What would torpedo a partial-verification story: the split discovered rather than disclosed. Volunteered, it's a migration narrative; found, it's a question about what else wasn't mentioned.
To answer the thread's closing question myself: what I would want as a buyer isn't more data — it's interpretive context on the events. A churn spike in month 9 reads as risk until the seller's build log (dated, public, contemporaneous) shows the pricing migration that caused it, with the diagnosis and the recovery. The Passport proves what happened; the log explains why; the two artifacts cross-corroborating is the strongest evidence package a small app can currently assemble, and both are free. That's the deliberate architecture of this platform in one sentence — and why the Show & Tell category's diligence thread and this one are ultimately the same thread wearing different categories.
Follow-up question: "Who else sees my Passport data besides buyers I authorize? Competitive sensitivity is real — transaction patterns reveal strategy."
The disclosure model, stated as policy: public surfaces show only what the badge system publishes — verification status and dated verified-period, never amounts or patterns (the public auction layer adds headline metrics you approve, per the auction-mechanics thread's anonymization design). Transaction-level access is authorization-gated per recipient — each buyer, each engagement, under the data-room NDA, revocable — and the platform side doesn't browse member Passports for editorial or any other purpose (verification checks run against the specific claims being verified, at your request, on stated dates). The competitive-sensitivity instinct is correct and the design agrees with it: the Passport's value is selective provability — the ability to prove everything to exactly whom you choose — not publicity. An asset that leaked strategy by default would be repriced by every seller correctly refusing to use it.