Crewmate
DeepAgent
MemeMint
Safenest
Tapvault
BitvmTapvault
Tecneural: Top Rated Software Development Services Company for 2026
Bitcoin Escrow
Powered by Taproot
A non-custodial, self-hosted Bitcoin escrow platform built on 2-of-3 Taproot multisig securing peer-to-peer trades, freelance milestones, and marketplace payments without ever holding customer funds
OVERVIEW
Escrow for Bitcoin, Without a Custodian
TapVault lets any two parties lock Bitcoin into a shared, rule bound address for the duration of a deal with no platform operator ever able to move those funds alone.
Traditional escrow requires trusting a company to hold your money. TapVault removes that requirement entirely. Every escrow generates a Taproot address controlled by three keys buyer, seller, and arbitrator where any two of the three are required to spend. The platform holds no private keys, so it cannot abscond with funds, freeze a deal, or be compelled to hand over customer balances
Private keys are generated and encrypted in the user's own browser using AES-256 and a signing password that never leaves the device. The platform stores only public keys, escrow metadata, and the resulting address enough to build and track transactions, never enough to spend them
TapVault ships as an open source, self hosted SaaS. Operators deploy it on their own infrastructure, apply their own branding, define their own escrow templates, and bill their own customers through Stripe owning both the platform and the revenue
Positioning
TapVault is infrastructure, not a marketplace. It does not match buyers with sellers or take custody of funds it supplies the cryptographic escrow layer that peer to peer marketplaces, freelance platforms, OTC desks, and trading communities can build on top of.
Non Custodial by Design
Keys are generated and encrypted client side; the platform never holds spending authority
Two of Three Multisig
Buyer, seller, and arbitrator keys form a Taproot address requiring any two signatures to release funds
Automatic Timelock Refund
A CSV timelock lets the buyer reclaim funds after a configurable period, with no arbitrator involvement needed
Private On Chain Footprint
MAST reveals only the spend path actually used a completed escrow resembles an ordinary Bitcoin transaction
Operator Owned
Open source, self hosted, white labelled, with no KYC requirement imposed by the software itself
Platform Components
Six Parts, One Escrow Platform
TapVault is made up of six distinct layers. Each has a different role and a different audience this section explains what each one does before the rest of the portfolio covers them in detail
Escrow Engine
The core service that creates and tracks escrows. It takes the three participant public keys, the agreed amount, and the timelock duration, then derives the Taproot address and script tree for that specific deal. It also manages escrow state created, funded, delivered, released, disputed, or refunded and drives every notification and status change in the interface
Client Side Key Management
The core service that creates and tracks escrows. It takes the three participant public keys, the agreed amount, and the timelock duration, then derives the Taproot address and script tree for that specific deal. It also manages escrow state created, funded, delivered, released, disputed, or refunded and drives every notification and status change in the interface
Taproot Script Builder
The component that assembles the MAST script tree for each escrow four tapleaves covering cooperative release, buyer side dispute, seller side dispute, and timelock refund and commits them to an unspendable NUMS internal key so no key path spend can bypass the agreed rules. It also constructs, combines, and finalizes the partially signed transactions for whichever path is eventually used
Invite & Onboarding Flow
An escrow is created by one party and joined by the other through a shared invite link. The counterparty opens the link in any browser, generates their own key, and confirms the deal terms no account provisioning, no app install, and no wallet extension required to participate
Arbitration Console
The interface used by the platform arbitrator when a deal is contested. It presents the escrow terms, the funding transaction, and the evidence submitted by both sides, then lets the arbitrator co-sign with whichever party is judged to be in the right. The arbitrator holds exactly one of three keys enough to break a tie, never enough to take funds unilaterally
Billing & Tenant Layer
The SaaS wrapper around the escrow product: NextAuth authentication, Stripe backed subscription plans, per tenant branding, and custom template configuration the layer that turns a self hosted deployment into a revenue generating service
How they connect
Key Management produces the three public keys. The Script Builder turns those keys and the deal terms into a Taproot address with four spend paths.The Escrow Engine then tracks that address on chain, while the Invite Flow, Arbitration Console, and Billing Layer wrap it into a usable product
Core Features
What the Platform Does
The feature set centres on four things: holding funds safely, making setup effortless, resolving disagreements fairly, and leaving as little trace on chain as possible
| Capability | Description |
|---|---|
| NonCustodial Custody | Private keys are generated in the user's browser and encrypted locally with AES-256 and a signing password. The platform never holds spending authority |
| 2 of 3 Taproot Multisig | Each escrow creates a Taproot address from buyer, seller, and arbitrator keys. Any two of the three signatures can move the funds |
| Instant Setup | An escrow can be created in under a minute. The counterparty joins from an invite link in any browser no app or extension install |
| Automatic Timelock Refund | A configurable CSV timelock allows the buyer to reclaim funds after the agreed period if the deal stalls, without arbitrator involvement |
| OnChain Privacy | Taproot MAST keeps unused spend paths hidden. Completed escrows are indistinguishable from ordinary Bitcoin transactions to outside observers |
| Multi-Template Escrows | Prebuilt templates for common deal types, plus fully custom templates defined by the operator |
| Address Verification | Both parties can independently verify the derived Taproot address before any funds are sent |
| Live Chain Tracking | Funding, confirmations, and settlement are tracked against the Bitcoin network in real time through a Blockbook compatible API |
Why it matters
Escrow is normally the point in a peer to peer trade where trust has to be handed to a third party. TapVault replaces that hand off with a spending policy enforced by Bitcoin script the arbitrator can influence the outcome of a dispute, but at no point can any single participant, including the platform operator, take the money
Escrow Lifecycle
Four Steps to a Secure Transaction
Every deal on TapVault follows the same path create, fund, deliver, release with dispute and refund routes available if it does not go to plan
1
Create the escrow
One party chooses a template, sets the amount, conditions, and timelock duration, then shares an invite link with the counterparty. Both sides generate their keys client side
2
Fund the address
Both parties independently verify the derived Taproot address. The buyer sends BTC to it, locking the funds under the 2 of 3 policy
3
Deliver the goods or service
The seller completes their side of the deal. The platform tracks confirmation status and escrow state throughout
4
Release the funds
The buyer approves and co-signs the release. The cooperative spend path is used, and the funds settle to the seller
Suggested agents for this sector
Dispute raised
Either party can escalate rather than release. Both sides submit evidence through the platform
Arbitrator reviews
The platform arbitrator examines the terms and evidence and co-signs with the winning party, releasing funds along the corresponding dispute path
Timelock expiry
If the escrow simply stalls and no one acts, the buyer can reclaim the funds once the CSV timelock matures no arbitrator, no platform intervention
Why it matters
Every outcome cooperation, dispute, or abandonment has a predefined, cryptographically enforced route out. There is no state in which funds become permanently stuck or dependent on the platform staying online
Architecture
Taproot MAST: How the Escrow Is Enforced
Every escrow is a Taproot output whose spending rules are committed to a hidden script tree. Only the branch actually used is ever
P2TR (Taproot) Addresses
Escrow addresses are SegWit v1 P2TR outputs the bc1p address format derived along BIP-86 paths and spent with Schnorr signatures. Taproot is what makes both the multi-path script tree and its privacy properties possible
The Four Spend Paths
The script tree contains four tapleaves. Each is a 2 of 2 tapscript requiring two specific signatures, except the refund path, which requires the buyer plus an elapsed timelock
| Spend Path | Required Signatures | When It Is Used |
|---|---|---|
| Cooperative release | Buyer + Seller | The normal outcome the deal completed as agreed |
| Dispute, buyer wins | Buyer + Arbitrator | Contested deal resolved in the buyer's favour. |
| Dispute, seller wins | Seller + Arbitrator | Contested deal resolved in the seller's favour. |
| Timelock refund | Buyer, after CSV maturity | The escrow stalled; the buyer reclaims funds automatically. |
Script Tree Structure
Unspendable Internal Key
A Taproot output can normally be spent silently through its internal key, bypassing the script tree entirely. TapVault prevents this by using a NUMS ("nothing up my sleeve") point as the internal key a point with no known private key. Because no key path spend is possible, every movement of escrowed funds must satisfy one of the four agreed script paths
Privacy Properties
Only the tapleaf that is actually executed is revealed when the escrow is spent. An observer watching the chain sees a spend, but not the other three branches, not the participant structure, and not the fact that the transaction was an escrow at all. A cooperatively released escrow looks like an ordinary Bitcoin payment
Independent verification
This section describes TapVault's implemented architecture for presentation purposes. Stakeholders evaluating the platform for production use should independently review the script construction, key handling code, and timelock parameters and conduct their own security audit before committing significant value to a deployment
Templates
One Platform, Every Use Case
Escrow terms differ by deal type. TapVault ships with prebuilt templates covering the most common cases, plus a custom builder for everything else
| Template | Built For |
|---|---|
| Freelance | Milestonebased payments between clients and independent contractors |
| P2P Trade | Bitcoin to fiat exchanges between individuals, where the fiat leg settles off chain |
| Domain Sale | Verified domain transfers, with release conditioned on registrar confirmation |
| Goods | Physical goods purchases with delivery tracking as the release condition |
| Rent / Deposit | Rental and security deposits held safely for the duration of a tenancy |
| Custom | Operator defined templates with bespoke conditions, timelocks, and terminology |
For marketplaces
A template maps directly onto an existing product flow, so escrow can be added to a marketplace without redesigning how deals are described to users
For operators
Custom templates let a deployment specialize an OTC desk, a domain broker, and a freelance platform can all run the same software with entirely different escrow semantics
Use case
A freelance marketplace could use the milestone template so each deliverable is funded into its own escrow released as work is accepted, refunded automatically via timelock if the client disappears, and arbitrated by the marketplace only when the two sides genuinely disagree
Disputes & Refunds
When a Deal Does Not Go to Plan
Two safeguards sit behind every escrow: an arbitrator who can break a deadlock, and a timelock that returns funds if nobody acts at all
Arbitrated Resolution
The arbitrator is a designated third key on every escrow typically the platform operator or a nominated neutral party. When a deal is contested, both sides submit their evidence, the arbitrator reviews the agreed terms, and then co-signs with whichever party prevails. Because the arbitrator holds only one of three keys, they can decide a contested outcome but can never take the funds themselves
Automatic Timelock Refund
Each escrow is created with a configurable CSV (CheckSequenceVerify) relative timelock. Once that period has elapsed after funding, the buyer can spend the refund path unilaterally and recover the deposit. This is the safety net for the worst case: a seller who vanishes, an arbitrator who becomes unreachable, or a platform that goes offline entirely
| Scenario | Resolution Path | Third Party Needed |
|---|---|---|
| Both parties satisfied | Cooperative release | None |
| Genuine disagreement | Arbitrated dispute path | Arbitrator |
| Seller unresponsive | Timelock refund to buyer | None |
| Platform offline | Timelock refund to buyer | None |
Why it matters
The timelock is what makes TapVault survivable independently of its operator. Even in a total platform failure, the buyer's funds are recoverable with nothing more than their locally held key and the escrow parameters
Self-Hosted SaaS
Deploy It, Brand It, Earn From It
TapVault is not offered as a hosted service you rent it is software you deploy, control, and monetize on your own infrastructure
Own the deployment
Run TapVault on your own servers, in your own jurisdiction, under your own operational policies.
Custom templates
Define escrow types that match your market, with your own terminology, conditions, and timelock defaults.
White-label branding
Apply your own identity across the interface so escrow feels native to your product rather than bolted on.
Stripe subscriptions
Built-in billing lets you charge your own customers on your own plans, with the revenue flowing to you.
Open source
The codebase is inspectable end to end important for a product whose entire value proposition is that it cannot keep your money.
No imposed KYC
The software does not require identity collection; operators decide what their own compliance posture needs to be.
| Tier | Included |
|---|---|
| Free | Three escrows per month enough to trial the full workflow end to end. |
| Pro | Higher escrow volume for active operators and growing marketplaces. |
| Enterprise | Unlimited escrows, custom templates, and white label deployment support. |
Compliance note
TapVault does not impose identity verification, but operators remain responsible for the regulatory requirements applicable to their own jurisdiction, customer base, and business model. This should be assessed before launch, not after
Technology Stack
Behind the Build
TapVault is built on a modern web stack with Bitcoin tooling handling everything cryptographic and nothing sensitive leaving the browser
| Layer | Technology | Role |
|---|---|---|
| Application | Next.js 16 | Fullstack framework serving the interface and API routes |
| Styling | Tailwind CSS 4 · DaisyUI 5 | Utilityfirst styling and component system for the whitelabelable UI |
| Data | MongoDB | Escrow records, participant public keys, template definitions, and state history |
| Bitcoin | bitcoinjslib | Address derivation, script construction, and transaction building |
| Addressing | Taproot P2TR | SegWit v1 outputs with BIP-86 derivation and MAST script trees |
| Signing | Schnorr signatures | Taproot native signing for all script path spends |
| Chain data | Blockbook API | UTXO lookup, funding detection, and confirmation tracking |
| Auth | NextAuth | Operator and participant authentication for the SaaS layer |
| Billing | Stripe | Subscription plans and payment handling for platform operators |
Why it matters
All key generation, encryption, and signing happen client side in the browser using bitcoinjs lib. The backend stores public keys and escrow metadata only so a full database compromise exposes deal records, never the ability to spend escrowed funds
Feature Summary
At a Glance
A complete summary of the TapVault escrow, security, template, and platform capabilities covered in this portfolio
| Feature | Category | Summary |
|---|---|---|
| Non custodial keys | Security | Client side generation, AES-256 local encryption |
| 2 of 3 Taproot multisig | Escrow | Buyer, seller, arbitrator; two signatures to spend |
| Cooperative release | Escrow | Buyer and seller co-sign the normal happy path |
| Arbitrated dispute | Escrow | Arbitrator co-signs with the prevailing party |
| CSV timelock refund | Escrow | Buyer reclaims funds automatically after expiry |
| MAST privacy | Security | Only the executed spend path is revealed on-chain |
| NUMS internal key | Security | No key path bypass of the agreed script rules |
| Invite link onboarding | Agents | Counterparty joins from any browser, no install |
| Address verification | Agents | Both parties confirm the address before funding |
| Prebuilt templates | Verticals | Freelance, P2P, domain, goods, rent, custom |
| White label branding | Deployment | Operator owned identity across the interface |
Note on independent verification
This portfolio describes TapVault's feature set and architecture for presentation purposes. Stakeholders evaluating the platform for production or investment use should independently verify the escrow script implementation, key handling practices, audit status, and deployment security before relying on it for meaningful value