CipherG was a founder-led P2P Bitcoin liquidity operation that grew from a small 2015 marketplace test into a serious operating system for marketplace trust, payment verification, customer support, and irreversible release decisions.
The operation later formalized as CipherG LLC in 2022, operated across multiple P2P marketplace environments, served 3,000+ customers, handled 10,000+ transactions, and was sunset in October 2024.
The commercial service is no longer active. That is intentional. A live service page would imply something current. The operating archive is the right reference point now: what was built, how the trust boundaries worked, which risks had to be managed, and why the model eventually stopped fitting the forward-looking environment.
By the early 2020s, the regulatory environment was shifting, a major marketplace had shut down, and fraud risk was at an all-time high. At the same time, legitimate ways to acquire Bitcoin had multiplied. The remaining demand became increasingly concentrated among people other services had already refused: customers who had burned other bridges and arrived at CipherG as a last resort. That adverse selection left the operation holding more of the downside risk as the surrounding market matured. The October 2024 sunset was the control for that changed environment — a deliberate exit from a model that no longer justified continuing, not a failed business running out of road.
What CipherG was
CipherG operated in the P2P Bitcoin market, where the hard problems were not only technical.
The work sat at the intersection of liquidity, payment verification, customer behavior, marketplace reputation, platform dependency, fraud pressure, support records, and irreversible crypto settlement.
The scale matters because it separates the archive from a casual trading story. This was not a small number of isolated transactions stretched into a lesson. It was a real operating environment with enough customer volume, payment activity, support burden, fraud pressure, and platform dependency to require a system.
How a release decision worked
Every trade ended in an irreversible act: releasing coins from escrow. The operating system existed to make that one act boring. It ran as four gates, in order, and a trade that failed a gate stopped there.
- Trust boundary. Who is on the other side: marketplace reputation and history, identity signals, and whether the request matched the account's established pattern. Third-party transactions were not allowed: the identity of the marketplace account holder had to match the person completing the transaction. A historical feedback ledger only means something when the account and the human are the same person; letting someone else transact through that account would make its record useless as evidence about the counterparty in front of you.
- Payment verification. Proof that the payment actually landed — in the named account, from the named payer, for the agreed amount — checked against the source of truth rather than a screenshot. A receipt is a claim; a cleared balance is evidence.
- Rail reversibility. Whether the payment could still be pulled back. A reversible or uncertain payment paused the process for more verification; unresolved reversal risk stopped the release.
- Dispute control. Records kept as if every trade would be disputed: timestamps, payment evidence, the conversation, and the release decision record. When a marketplace dispute or a chargeback arrived, the file already existed, which is what turned disputes from emergencies into paperwork.
Drawn as one flow, those four gates are the whole system. The shape is the point: identity before money, evidence before belief, reversibility before release, and a record before it is needed.
What the work proved
CipherG is part of my portfolio because it shows founder/operator judgment under real constraints.
The useful proof is not “crypto experience” by itself. The useful proof is the operating discipline around:
- marketplace trust
- payment-rail reversibility
- irreversible release decisions
- customer support under pressure
- dispute evidence
- platform dependency
- fraud patterns
- documentation
- controlled exit discipline
A system involving irreversible value transfer cannot run on optimism alone. It requires controls, records, judgment, and the ability to refuse revenue when the model no longer meets the standard.
Why it matters now
CipherG is no longer an active service, but the operating lessons still matter.
The work connects directly to business systems, technical operations, platform risk, and the design of trust boundaries. It also connects to my broader research on overlays: the gap between what an interface makes simple and what remains complex underneath.
Full operating archive
The full record is available as a research archive:
Read the CipherG Operating Archive
Background material only. This page is not investment, trading, financial, tax, legal, or compliance advice. CipherG is no longer an active service.