# How to prove a year of freelance income from onchain records A practical guide for freelancers and their accountants on building an airtight income-verification dossier from Ethereum transaction records, and how onchain payment routing makes that dossier almost automatic. --- For all the freedom that comes with being your own boss, there is one situation that stops even the most seasoned freelancer cold: the moment someone asks for proof of income. Apply for an apartment lease, a mortgage pre-approval, a business line of credit, or a visa renewal, and the demand is the same — show me the money, in writing, verified by something other than your own say-so. The financial world was built around traditional employment — predictable salaries, employer-issued documentation, and neat W-2 forms that wrap everything up at year-end. Freelancers don't fit that mold, and proving income without an employer can feel like trying to translate a language no one around you speaks. That problem is solvable. And for freelancers who receive some or all of their income onchain — in stablecoins or other tokens routed through Ethereum — the solution is actually more robust than most people assume. This article walks through the full picture: what institutions genuinely want to see, what onchain records actually contain, how to build them into a presentable dossier, and why the structure of an onchain payment — one incoming transfer, preset splits, simultaneous distribution — creates almost automatic documentation as a byproduct.
$14,000credited directly to the lead contractor on a $20,000 three-party deal, with no pass-through transfers
$98,400in yearly gross receipts a solo consultant proves with eight transaction hashes
$139,500one member's 45% share of $310,000 across nineteen projects, legible from his wallet alone

Figures from the worked examples in this article: the routing example and scenarios A and B.

## Why income proof is harder than it looks for freelancers Start with the simplest version of the problem. 1099 contractors receive IRS Form 1099-NEC from clients rather than W-2s from employers. They work for multiple clients, earn variable income across different payment sources, and lack the consistent monthly paycheck that lenders use as the baseline for income verification. That variability is the crux. A freelance graphic designer earns strong revenue but has no W-2 to place in front of a loan officer. One lender declines the application because the tax returns show heavy business deductions. Another lender reviews the deposits, business records, current earnings, and continuity of the work, then approves the borrower under a different program. The difference between those two outcomes is almost always documentation — not how much money the freelancer earned, but how clearly they can demonstrate it. The lender wants to know whether the borrower has enough income to repay the mortgage, whether that income is being received now, and whether it's likely to continue. The practical documents institutions request are well established. If you are self-employed and trying to obtain a mortgage, the typical documentation will be: two years of filed federal tax returns (including a completed Schedule C), a current year-to-date Profit and Loss Statement, and two to three months of business bank statements. Some mortgage programs require a CPA letter that verifies the self-employed individual's status and their reported income. Typically a lender will require two years of consistent income from a self-employed individual in order to verify that their reported income is not merely a one-time occurrence. For rental applications the bar is a bit lower. Most institutions ask for three to six months of statements for rental applications and up to 12–24 months for mortgage pre-approvals. The point is not that onchain income bypasses these requirements. It does not, and it should not — these verification layers exist for good reasons. The point is that well-structured onchain records satisfy these requirements *better* than traditional payment records in several important ways. The rest of this article is about building that case. ## What an Ethereum transaction record actually contains Every confirmed transaction on Ethereum carries a fixed set of data that is publicly accessible, permanently stored, and cryptographically linked to every transaction before and after it. The ledger transforms traditional log management into a verifiable, cryptographic chain where every entry is cryptographically linked to the previous one, creating an unbreakable audit trail that stands up to forensic examination. The specific fields inside any transaction relevant to income verification include: - **Transaction hash (TXID):** A unique 66-character identifier that locates the exact transaction on any public blockchain explorer. No two transactions share one. - **Block number and block timestamp:** The precise moment — accurate to the second — at which the transaction was confirmed on the network. - **From address:** The wallet that initiated the transfer. - **To address:** The contract or wallet that received it. - **Value and token:** The exact amount, in the exact token (e.g., USDC, USDT, ETH), with no rounding. - **Input data / method call:** For contract interactions, the full data field showing what function was called and with what parameters. - **Gas fees paid:** The network fee, recorded as part of the permanent state. The core capability lies in the ability to create entries that cannot be altered retroactively once committed to the ledger. This immutability is achieved through cryptographic hashing, ensuring that any attempt to modify a past record would immediately invalidate the subsequent chain. What that means in practice: a client paid $12,000 (approximately AUD 18,600) on March 14 at 14:22:07 UTC. That fact is recorded. It was recorded automatically. It is accessible to any accountant, underwriter, or regulator with an internet connection. It cannot be edited. It has never required any action on the freelancer's part to preserve it. Finality is a guarantee that, at a certain point, a particular transaction is confirmed and recorded on the blockchain, and cannot be reversed, modified, or canceled. There is no equivalent of a returned ACH transfer, a disputed wire, or a voided check. Once an onchain payment settles, it is settled. This quality — permanence — is exactly what income verification reviewers are hunting for when they sift through bank statements and tax forms. Every payout generates a complete, exportable record: transaction ID (TXID) for blockchain verification, timestamp, network fees, and recipient information. A freelancer who receives twelve project payments over a calendar year has twelve such records, each independently verifiable by any third party. ## The specific advantage of payment routing: one transaction, clean attribution Here is where the structure of onchain payment routing matters more than most freelancers realize. Consider a common freelance arrangement: a multi-party project where the client owes $20,000 (approximately AUD 31,000) total — $14,000 to the lead contractor, $4,000 to a subcontractor, and $2,000 to a production studio for deliverables. In a traditional wire-transfer workflow, the client sends one transfer, the lead contractor receives the full $20,000 into their account, then initiates two more outbound transfers from their own funds. The result is three separate events, two of which look like outgoing payments from the lead contractor's records. An underwriter reading those bank statements sees gross receipts of $20,000 followed by what appear to be two discretionary outflows — which can complicate the income picture. This is precisely the scenario that a payment router like [shaka.deal](https://shaka.deal) is designed to resolve cleanly. The client sends one transaction, the router reads preset share parameters, and it distributes all three amounts simultaneously — in a single block, in a single settlement event. | Party | Traditional wire workflow | Routed through shaka.deal | | --- | --- | --- | | Lead contractor | Receives the full $20,000, then sends two outbound transfers | $14,000 credited directly | | Subcontractor | $4,000 forwarded from the lead contractor's funds | $4,000 credited directly | | Production studio | $2,000 forwarded from the lead contractor's funds | $2,000 credited directly | Three separate receiving addresses, three separate credit events, all traceable to one originating transaction hash. The documentation advantages compound immediately. The lead contractor's wallet history shows only the $14,000 credit — their actual income — not a gross receipt followed by ambiguous outflows. The subcontractor's wallet shows $4,000 arriving directly from the deal contract, with a clean timestamp. No party's records are obscured by pass-through transfers that look like income when they are not. This split-instant-certain structure is the operational core of how shaka.deal works. One incoming payment, preset shares, simultaneous payout, final settlement. The non-custodial architecture means the router never holds funds in transit — the distribution happens atomically within the transaction execution itself. For income documentation purposes, this matters: there is no intermediate state, no holding period, no internal ledger to reconcile. The blockchain record reflects the economic reality of the deal without any translation layer. ## Building a 12-month income dossier from onchain records Now for the practical work. A year's worth of onchain income, properly organized, can serve as a strong foundation for the documentation packages lenders and landlords request. Here is how to build it. ### Step 1 — Maintain a dedicated business wallet address Do not mix personal crypto activity with freelance payments. A separate wallet or exchange account makes bookkeeping, tax reporting, and client tracking easier. It also helps if an exchange, accountant, or tax authority asks for transaction records. This single discipline — one address for work income, different addresses for personal activity — transforms your wallet history into something that reads like a business bank statement. Every incoming credit at that address is a client payment. Every outgoing transaction can be labeled. The separation is visible at the blockchain level, not just in a spreadsheet. ### Step 2 — Export a full transaction history with fiat equivalents Blockchain explorers (Etherscan is the standard for Ethereum) allow full export of any address's transaction history to CSV. The export includes transaction hash, block number, timestamp, counterparty address, token amount, and token type. The one field the blockchain does not contain is the USD or AUD equivalent at the time of receipt. This is where a reputable price-data source — CoinGecko historical prices, Coinbase transaction exports if custody is held there, or a dedicated crypto accounting platform — is needed. ### Step 3 — Create a deal-by-deal income ledger The raw transaction export is necessary but not sufficient. Assemble a reconciled ledger that maps each incoming transaction to: - **Client name or entity** - **Invoice number** (issued before payment) - **Project description** - **Gross contract value** in USD (AUD equivalent) - **Your share** (for multi-party deals routed through a distribution contract) - **Transaction hash** linking to the on-chain record - **Date of receipt** (block timestamp) - **Fiat value at receipt** For freelancers using shaka.deal, this ledger is straightforward to populate: each deal has one originating transaction hash. The share parameters embedded in the routing transaction confirm your portion of the deal without requiring any additional documentation. The ledger entry is: TXID → your address → amount received → USD equivalent on that date. ### Step 4 — Prepare a Profit and Loss statement Creating regular profit and loss statements for your business is actually good practice for any freelancer, even if you don't use them as evidence for lenders and landlords. These documents uncover patterns in income and expenses, and allow you to be better prepared for likely high or low income months. Your P&L for an onchain income year should show: - **Gross receipts:** Total fiat value of all incoming onchain payments, organized by month - **Business expenses:** Network fees paid (gas), software subscriptions, professional services, equipment - **Net income:** The figure your CPA will translate to Schedule C The blockchain export makes gross receipts unusually verifiable. Each line item in the P&L can be tied back to a public transaction hash that any counterparty can independently confirm. ### Step 5 — Engage a CPA who understands crypto income A CPA income verification letter — also called a comfort letter or third-party verification letter — is a formal document prepared by a licensed Certified Public Accountant that confirms a client's income, employment status, or business ownership to a third party. It is signed by the CPA based on a review of the client's tax returns, profit and loss statements, and financial records. For higher-stakes applications — mortgages, business loans, or premium rentals — a letter from a licensed CPA verifying your income and self-employment status carries significant weight. The letter should confirm how long you've been self-employed, your average annual income over the past one to two years, and your overall financial stability. A CPA who has handled crypto-income clients before will know how to reference the onchain records in the comfort letter, tie the transaction exports to the filed Schedule C, and present the whole package in language an underwriter recognizes. The blockchain records are the raw source material; the CPA's letter is the translation into institutional language. Both are needed, and together they are substantially stronger than either alone. A CPA letter for a 1099 contractor confirms three critical facts: the total annual income earned across all sources as reported on filed tax returns, the consistency of income over the two most recent tax years, and the active status of the contractor's freelance or consulting practice. When the raw records are onchain, the first of those three facts is independently verifiable by the lender's own analyst — a level of self-evidence that no bank statement can match. ## Scenario walkthroughs ### Scenario A — The solo UX consultant applying for a mortgage Priya is a UX consultant based in Austin. Over the past year, she completed eight contracts ranging from $4,000 to $22,000 (approximately AUD 6,200 to AUD 34,100), all paid in USDC through Ethereum. Her total gross receipts for the year were $98,400 (approximately AUD 152,500). She maintains a dedicated Ethereum wallet for client payments, labeled clearly in her accounting software. Each contract went through shaka.deal: the client sent USDC, the router confirmed her wallet address as the sole recipient at 100% share, and the funds settled in one transaction. Eight contracts, eight transaction hashes, all timestamped, all publicly verifiable. Her documentation package for the mortgage pre-approval: a full CSV export from Etherscan for her business wallet address, annotated with client names and invoice numbers; a P&L statement prepared by her CPA mapping each TXID to its USD value at receipt; two years of filed tax returns with Schedule C; and a CPA comfort letter confirming $98,400 in gross receipts for the year with reference to the specific transaction hashes examined. The underwriter can independently confirm every number against the public ledger. The application moves to approval without a request for additional documentation. ### Scenario B — The three-person creative collective applying for a commercial lease Marcus, Yolanda, and Sven operate a video production collective. Clients pay a single project fee; the three creatives split every deal at preset percentages — 45/35/20 — using shaka.deal to route the distribution automatically. Over twelve months, they completed nineteen projects with a combined value of $310,000 (approximately AUD 480,500). Marcus is applying for a commercial lease on a studio space. The landlord wants to verify his personal income from the collective. The challenge in a traditional payment structure would be significant: Marcus's bank statements would show gross deal amounts if funds passed through his account, obscuring his actual 45% share. Because shaka.deal routed each project payment directly to each party's wallet at settlement — simultaneously, in one transaction — Marcus's wallet history shows only his 45% share for each project, credited directly from the routing contract. His income is legible from the raw transaction history without any additional explanation. His accountant exports his wallet's twelve-month history, confirms total receipts of $139,500 (approximately AUD 216,200), prepares the P&L, and writes the verification letter. The landlord receives a dossier where every credit in Marcus's wallet history corresponds directly to a documented project. ### Scenario C — The freelance developer pursuing an SBA loan Diego runs a software development practice and has been growing it for three years. He wants a small business loan to hire two part-time contractors. The SBA lender requires two years of tax returns, a year-to-date P&L, and bank or equivalent account statements. Diego's equivalent of bank statements is his onchain wallet history, exported from Etherscan and formatted into a readable register. His CPA has worked with crypto income before and knows how to present the documentation. The lender's underwriter looks at the export with initial skepticism — this is not a Chase statement — but the CPA's letter explains the nature of the records, cites the public verification methodology, and maps each transaction to the corresponding tax-year Schedule C line. By leveraging distributed ledger technology, organizations can maintain a permanent, tamper-evident history of transactions and events. Such a history is specifically designed to meet the stringent requirements of financial regulators and internal auditors who demand absolute proof of past actions. The underwriter, satisfying themselves that every figure is independently confirmable, moves forward. The loan closes. ## Common objections and how to answer them **"The lender won't recognize a blockchain export."** This is increasingly untrue, and preparation neutralizes it entirely. Major U.S. mortgage lenders have begun accepting crypto assets in qualification. Borrowers can now use Bitcoin, Ethereum, and USD-pegged stablecoins as assets and income evidence for mortgage approvals. More importantly, the blockchain export is not asking the lender to trust an unfamiliar institution — it is giving them independently verifiable data. A CPA letter that explains how to read the export and ties each line to a filed tax return eliminates the interpretive friction. **"Crypto income is too volatile to show stability."** Stablecoin income is not volatile — USDC or USDT denominated in USD terms is stable by design. More broadly, the volatility objection applies to assets held, not income received. A freelancer who invoices in USD-equivalent stablecoin and converts to fiat upon receipt can show exactly the same stability picture as someone paid by wire. The onchain record confirms the amount and the date; the CPA confirms the fiat value at that date. Nothing in that chain depends on what ETH or BTC did between project milestones. **"My records only show one year, not two."** Some lenders may be willing to consider a mortgage based on one year of returns and provide additional requirements to verify income. One year of clean, verifiable, timestamped onchain records — especially for a growing practice — can support that alternative pathway better than a mixed-source first year of traditional bank statements. Start building your onchain record now; the second year will arrive. **"What if the client paid through multiple wallets or tokens?"** This is where the deal ledger discipline pays off. Each payment is a distinct transaction hash. Whether the client paid from one wallet or three, each transfer is permanently attributed to its sending address, its receiving address, its token, and its timestamp. The reconciliation work is done at the ledger step — match each credit to its corresponding invoice, note any token conversion, and present the result as a single income line for that project. Messiness in the payment method does not create messiness in the record; the blockchain captured everything. ## What to give your accountant at year-end At the end of each fiscal year — or in January before tax season begins — hand your CPA the following package: 1. **Full Etherscan CSV export** for every business wallet address, covering the complete fiscal year. Label each address clearly (e.g., "Primary business receipts wallet"). 2. **Annotated deal register** matching each incoming TXID to client name, invoice number, project description, and gross contract value. 3. **Historical price data** for each token received, at each receipt date, from a consistent and reputable source. 4. **Any contract or SOW documents** referenced in the deal register — signed project agreements, purchase orders, or client-issued confirmations. 5. **Gas fee summary** — total network transaction costs paid during the year, which are deductible as a business expense. Your agreement or invoice, ideally backed by a properly executed e-signature on your contract documents, should include the project fee, payment deadline, token, blockchain network, wallet address, and who pays transaction fees. When those contract terms are already documented before the transaction occurs, the year-end package almost assembles itself — contracts define the terms, transaction hashes prove execution, and the price data establishes fiat value. Blockchain platforms store your transaction and project records securely and immutably. The practical consequence of that immutability is that a freelancer who works onchain is not dependent on any institution's goodwill to preserve their records. No bank can close an account and erase the history. No payment platform can suspend access and lock out export functionality. The record is on the public ledger, permanently, under the freelancer's own wallet address, retrievable at any time by anyone with a block explorer and an internet connection. ## Looking forward: onchain income as a first-class documentation source In 2026, more than 90% of U.S. workers have either considered or are actively engaged in some form of independent work — whether that's full-time freelancing, consulting, or gig-based contracting. The institutions that serve this workforce — lenders, landlords, accountants, underwriters — are rapidly developing the literacy to evaluate non-traditional income records. The gap between "this is unusual" and "this is acceptable" is closing quickly, and the freelancers who will cross it fastest are those who have built clean, verifiable, year-over-year onchain records before they need to present them. The structural advantage of using a payment router like shaka.deal is not merely operational convenience. It is that the economics of every deal — who received what, in what amount, at what moment — are baked permanently into the public ledger by the routing transaction itself. One incoming payment. Preset shares. Simultaneous distribution. Final settlement. The income record is not constructed after the fact from memory and invoices. It is written into the chain at the instant the deal closes. For a freelancer preparing a mortgage application or a lease submission, that architecture means the hardest part of the documentation work — proving that money actually moved, in the claimed amounts, on the claimed dates, to the claimed parties — is already done before the application process begins. The remaining work is translation: turning the onchain record into the language that institutions expect, with the help of a CPA who knows both sides of that translation. That is a solvable problem. And unlike most problems in freelance finance, it gets easier every year you build the record rather than harder.