How MemberDrive accepts Bitcoin without holding it

Oct 7, 2026 · @Ryan Heneise

When a donor gives Bitcoin through MemberDrive, the coins go straight from the donor's wallet to the organization's own wallet. MemberDrive never holds the coins, never holds a private key, and can't move a single satoshi. We only watch the public network and record the gift, and we charge no fee for it. This post explains how Bitcoin makes that possible, and how our side of it works.

How Bitcoin works, briefly

Bitcoin is a shared ledger that no single company runs. Thousands of computers (nodes) each keep a full copy and check every change against the same rules. A few ideas carry the rest of this post:

Keys. A wallet holds a private key and the public key that comes from it. The private key signs payments. The public key can be shared freely; it can't sign anything.
Addresses. An address is a short code made from a public key. Anyone can send Bitcoin to it. Only the holder of the matching private key can spend what arrives.
Transactions. A payment is a signed message that spends earlier coins and creates new outputs, each locked to an address. One transaction can pay several addresses, for example the recipient and the sender's own change.
The mempool. A new transaction is broadcast to the network and waits in each node's mempool, a holding area for payments not yet in a block. It is public from that moment.
Blocks and confirmations. About every 10 minutes, a miner adds a block of waiting transactions to the chain. Each later block adds one more confirmation and makes the payment harder to reverse.

The important part: the whole ledger is public. Anyone can see which addresses received which amounts, without asking anyone's permission. That is what lets MemberDrive recognize a donation without ever being in the money's path.

What self-sovereign means for a donation

Most platforms that take crypto use a custodian: the donor pays the processor, the processor holds the coins, and later it pays the organization, often in dollars and after a fee. That adds a company that can freeze funds, get hacked, or go out of business with your money inside.

Self-sovereign means the organization holds its own keys, and the payment goes directly to them. With MemberDrive:

The organization's wallet is the only place the Bitcoin ever lands.
No one at MemberDrive can spend, freeze or redirect a donation.
If MemberDrive went offline tomorrow, every coin already received would still be in the organization's wallet, under its own control.
MemberDrive charges no fee on Bitcoin donations: 0%, $0. Our 1% platform fee applies only to card and bank (ACH) payments processed through Stripe.

The only cost of a Bitcoin gift is the network fee. The donor sets it in their own wallet when they send the payment, and it goes to the miner who includes the payment in a block. Neither MemberDrive nor the organization receives it.

The picture

[embed: node/724639b6-a428]

The money moves on one path only: from the donor's wallet, across the network, into the organization's wallet. MemberDrive sits beside that path. It hands the donor an address and an amount, and it reads the public ledger to see when the gift arrives.

A fresh address for every donation

To connect Bitcoin, an organization pastes one value into MemberDrive: its wallet's extended public key, often called an xpub or zpub. That is the only Bitcoin credential we ever store.

Modern wallets are hierarchical deterministic (HD) wallets, defined in BIP-32. From one master key they derive a long, numbered chain of child keys. The extended public key is the public half of that tree. With it, anyone can compute the wallet's receive addresses: number 0, 1, 2 and so on. Without the private half, no one can spend from any of them.

We use this to give every donation its own address. When a donor opens the Bitcoin checkout, MemberDrive takes the next number in the sequence and derives that address. The organization's wallet derives the very same list, so the payment simply shows up there. When you connect a wallet, MemberDrive shows the first few addresses so you can check that they match your wallet.

A fresh address per gift does two jobs:

Matching. Any payment to that address belongs to that donation, so we know who gave without asking the donor for a memo or reference.
Privacy. Reusing an address links payments together on the public ledger. One address per gift keeps donors' gifts separate from each other.

One side effect: a donor who opens the checkout and leaves still uses up an address. So an organization's wallet can show gaps between used addresses. That's expected, and it's why we recommend a new wallet just for donations.

Pricing the gift and recognizing the payment

Donors think in dollars, so a gift starts as a dollar amount. MemberDrive fetches the current BTC/USD price and converts the gift to an amount in satoshis (one hundred-millionth of a bitcoin). The checkout shows that amount and a QR code in the standard BIP-21 format, which carries the address, the amount and a short label. Most wallets fill in everything when they scan it.

Then we watch. Because the ledger is public, we can ask a block explorer what has been paid to the donation's address, with no account and no permission. We look at the mempool, not only at confirmed blocks, so the donor sees a thank-you within seconds of sending.

Real donors don't always do what the checkout says, so the matching is forgiving:

Rounded amounts. Many donors type a round number instead of the exact amount. We accept a payment within 10% of the expected amount.
Split payments. Some donors send a small test payment first and the rest later. We add up everything paid to the address, so the two payments count as one gift.
Late payments. A donor may leave the page and pay an hour later. After the first few minutes, a scheduled check keeps watching unpaid donations, often at first and less often later, for seven days.
Old payments. If an address was ever used before, payments confirmed well before the donation started are ignored.

When the total matches, MemberDrive records the gift, sends the receipt and links each transaction to its public record. The amount in the receipt is what actually arrived on the network, not the estimate.

What we never touch, and the trade-offs

MemberDrive never sees a private key or a seed phrase, and never asks for one. We hold no coins, run no exchange and never convert a gift to dollars. The extended public key we store can derive addresses, but it can't spend from them.

That design comes with honest trade-offs:

The extended public key reveals the wallet's history. Anyone who has it can see every address the wallet derives, and so every payment to them. We keep it encrypted, and we recommend a separate wallet just for donations.
We read the chain through a public explorer. Watching addresses through a public service is simple and needs no infrastructure, but that service can see which addresses we look up. Running our own node would remove that exposure.
We record a gift before it confirms. Recording at the mempool stage gives donors an instant thank-you. A payment could still be replaced before it confirms. For a donation, where nothing ships, we think that's the right balance.
The dollar value is an estimate. The price can move between the checkout and the payment. The receipt records what arrived on the network.

The result is a donation flow that feels like any other checkout to the donor, while the money moves exactly the way Bitcoin was designed to: from one person directly to another.