Gainz: Private Crypto Tax Reconciliation

Gainz guides users through incomplete crypto records one decision at a time.
Financial records remain on the user's computer, with no Gainz cloud account or transaction upload.
Import exchange records without beginning with a complicated transaction table.
Gainz keeps quantity, gross value, source fees, total cost, and net proceeds separate and reviewable.
Ambiguous withdrawals become plain-language decisions supported by nearby source context.
Current holdings give Gainz an independent checkpoint for identifying missing transaction history.
Gainz explains what is missing and what to investigate without pretending that lost history was recovered.
Supported and unresolved amounts are separated before a taxpayer or professional chooses a treatment.
Proceeds, basis, holding period, evidence, and professional direction are recorded as separate facts.
Every proposed treatment shows its fee-aware before-and-after tax impact before it is applied.
Gainz clearly separates completed checks from items that still block filing-ready output.
Users can inspect copied files, references, missing evidence, unresolved items, and draft status before generation.
Gainz compares calculated totals with filed-return and payment evidence without conflating the two.

Inspiration

Like many people in the United States, I reached tax season and realized I did not really understand how to report my cryptocurrency activity.

I initially thought, “I haven't done that much with crypto. How difficult could this be?” I opened Excel and started reconstructing my transactions. It quickly became clear that calculating cost basis was much harder than I expected.

Records came from different platforms and used inconsistent formats. Transfers between my own wallets looked like disposals. Some transactions were missing acquisition history. Even when the arithmetic was possible, documenting why a particular tax treatment was chosen was another problem entirely.

I started building Gainz in Python (Pre ChatGPT) to solve that problem for myself.

The project eventually stagnated. As AI development tools improved, I returned to Gainz with Codex as a development partner. That changed what felt possible. Instead of merely producing calculations, Gainz could become a guided reconciliation product that helps someone work through incomplete records one decision at a time.

My goal is simple: if Gainz can help someone move from “I do not know what happened here” to “I understand this, it is documented, and I can discuss it with my tax professional,” then the project is worthwhile.

What Gainz Does

Gainz is a private, offline application for reconciling incomplete cryptocurrency tax records.

Users import transaction files from exchanges and payment platforms, declare their current holdings, and work through discrepancies in a guided sequence. Gainz distinguishes between documented facts, calculated values, user decisions, unresolved questions, and tax-professional direction.

Rather than silently inventing missing history, Gainz identifies what it knows and what remains unsupported. It helps users investigate likely explanations, record evidence, and prepare unresolved matters for professional review.

When sufficient information is available, Gainz can generate tax workbooks and an audit packet containing reconciliation details, assumptions, evidence references, decision history, and CPA-facing workpapers for professional review.

All processing and storage remain on the user’s computer. Private financial records do not need to be uploaded to Gainz or sent to a hosted service.

How I Built It

Gainz is a Python desktop application with a local web interface. The application runs on the user’s computer and stores its working data, revisions, uploaded source files, exports, and audit packets locally.

I used Codex throughout the renewed development process to help:

Investigate parsing and accounting behavior
Implement guided reconciliation workflows
Design safer handling for incomplete records
Build regression and end-to-end tests
Review the application from a new user’s perspective
Improve accessibility, interface hierarchy, and instructional language
Validate packaged Windows releases
Review documentation and public product positioning

For this project, I used two separate Codex sessions with clearly defined roles. One session acted as a user and product assessor. It tested the packaged application through the browser without changing any code, then produced an independent assessment of the experience, its blockers, and opportunities for improvement.

The second session served as the improvement workflow. It implemented those findings, incorporated my additional direction, added regression tests, and prepared and verified releases.

This created a repeatable loop: use the product, identify confusion, document the problem, improve the implementation, and test it again. That loop helped turn Gainz from a spreadsheet helper into a guided reconciliation product.

The process was highly iterative. I would use the packaged application as a real user, identify where I became confused or uncertain, and then work with Codex to turn that confusion into a clearer product decision.

A principle emerged from those reviews:

Walk me through this mess one decision at a time.

That principle now guides the product. Gainz should always explain the current task, why it matters, and the safest next action without overwhelming the user with controls that are not yet relevant.

Build Week Extension

Gainz existed before OpenAI Build Week. For the hackathon, I am meaningfully extending the existing project using Codex and GPT-5.6.

The Build Week work focuses on making incomplete-record resolution more transparent, reviewable, and useful to tax professionals. The new workflow is designed to show:

Which values came directly from source records
Which values Gainz calculated
Which quantities lack documented basis
What assumption is being proposed
How fees affect proceeds and basis
What the tax impact would be before applying a decision
Who directed or recorded the treatment
What evidence supports the decision
How the decision appears in the final CPA workpapers

I am documenting the pre-hackathon baseline separately from the functionality added during the submission period. Dated commits and Codex session records provide the development history.

Challenges

Incomplete records are not just a calculation problem

The hardest cases are not ordinary buys and sells. They are transactions where the records do not fully explain what happened.

A withdrawal might be a transfer to the user’s own wallet, a payment, a gift, a lost account, or a disposal. Those possibilities have different tax consequences. Software should not automatically choose one merely because it makes the numbers reconcile.

Gainz therefore separates investigation from resolution. It presents likely explanations and evidence to look for, but requires the user or tax professional to make and document material decisions.

A mathematically valid result can still be misleading

Tax calculations depend on more than quantity and price. Fees, acquisition dates, holding periods, transaction classifications, and the origin of each value all matter.

One of the most important lessons from development was that a polished report is not enough. Every important total must be traceable to imported evidence, an explicit calculation, or a documented decision.

Privacy changes the product architecture

Many financial applications are cloud services. Gainz is intentionally offline because users should not have to upload years of sensitive financial records merely to organize them.

That choice improves privacy but introduces other challenges. The packaged application must reliably manage local storage, imports, revisions, exports, and platform-specific file behavior without depending on a hosted backend.

Tax software must communicate uncertainty honestly

Gainz is not a substitute for a CPA, enrolled agent, or tax attorney. It must avoid presenting assumptions as recovered facts or unverified user entries as professional approval.

The interface and exported workpapers therefore need precise language about what is known, what is assumed, what remains unresolved, and what requires professional judgment.

What I Learned

I learned that reconciliation is as much about evidence and decision-making as it is about arithmetic.

Users do not need another enormous transaction table. They need the product to answer three questions:

What is wrong?
What should I look for?
What is the safest next step?

I also learned that privacy can be more than a technical feature. For Gainz, offline operation defines the relationship with the user: their financial history remains theirs.

Most importantly, I learned how effective AI-assisted development can be when it remains a collaboration. Codex accelerated implementation, testing, research, and product review, while I remained responsible for the product direction, tax-policy boundaries, risk decisions, and final acceptance of the work.

What Is Next

The next stage is to validate Gainz with more real-world file formats and obtain structured feedback from CPAs and enrolled agents.

The long-term goal is not to replace professional judgment. It is to make the difficult work before that conversation much easier: organize the records, expose the gaps, document the decisions, and provide a professional with something they can efficiently review.

This is my first hackathon. I joined because Build Week offered an opportunity to improve Gainz, learn from other builders, and introduce the project to people who may have faced the same problem.

The outcome I am working toward is hearing someone say: