Anyone can launch.
Each token’s creator fee is earmarked for its church.

HolyPad is a launchpad on the pump.fun protocol on Solana, for tokens launched for churches. Launching works exactly like pump.fun: connect a wallet, fill in the token, sign the create transaction, and the token is trading. The one difference is who the token’s on-chain creator is. pump.fun pays a token’s creator a fee on trades. On HolyPad every token gets a fee wallet of its own as its creator, made by HolyPad for that token and used for nothing else, so the creator fees a token earns are its own, earmarked for the church it is named for. HolyPad’s engine sweeps each token’s fees to the HolyPad donation wallet with a record against that token, and HolyPad donates each token’s total to its church by hand, publishing each donation with proof on the donations page. A church that has registered a Solana address with HolyPad, or publishes one on its own site, is paid more directly: each sweep of a token bound to it goes straight to that address.

Plainly: anyone can launch a token named after any church. HolyPad does not vet launchers, does not check whether a launcher has anything to do with the church they name, and gives out no verification badge. No church has consented to, endorsed, partnered with or asked for a token unless its token page says the church consented in writing (the consent rule).

HolyPad is a for-profit launchpad that gives away the creator fees of every token launched on it. It is not a charity, a nonprofit or a foundation. Buying, holding or trading a token is not a donation to anyone.

A launch is a form and a signature:

1. Connect a wallet and sign in with it. Signing in is a signed message, not a transaction.
2. Fill in the token. Name, ticker, description and image; optionally the church’s name and where it is, and a website, X or Telegram link. This saves a draft. One open launch per wallet at a time.
3. Sign the create transaction. HolyPad uploads the token’s metadata, makes the token’s fee wallet and builds pump.fun’s create instruction with that fee wallet as the token’s on-chain creator. The same transaction sends 0.01 SOL from you to the fee wallet, so it can pay for its own sweeps. You sign it in your wallet and pay for it. When it confirms, the token is trading on pump.fun and has its page here.

Before it builds that transaction the server checks two things: fee routing is ready (it can make the token’s fee wallet, and the donation wallet the fees are forwarded to is set), and the launch is still open. Nothing else is checked. No camera, no microphone, no minimum time on air, no pledge.

What it costs. The network fee, pump.fun’s token creation cost and 0.01 SOL to the token’s own fee wallet, all paid inside the create transaction you sign. That is the whole cost: HolyPad charges nothing to launch. The 0.01 SOL is not HolyPad’s: about 0.005 SOL stays in the fee wallet as the reserve that pays for its sweeps, and the rest goes on with the fees. What leaves a token for the donation wallet is its creator fee plus that unspent part of the top-up, earmarked for the token’s church; while the engine is in dry run nothing leaves at all. The launcher receives none of it.

pump.fun pays a token’s on-chain creator a creator fee: currently 0.30% of trading volume while the token is on the bonding curve, and a smaller share after it graduates. The fee accrues in a creator vault pump.fun keeps for that creator, and in a separate PumpSwap creator vault after graduation, until the creator claims it. pump.fun does not guarantee that any creator fee is charged or distributed, the share falls at higher market caps and is zero in some pools, and pump.fun’s terms allow control of a token’s creator fee to change hands through a community takeover (pump.fun fees, terms).

On HolyPad the creator named in every create transaction is that token’s own fee wallet, a wallet HolyPad makes for the token when it is created and uses for nothing else. It is written into the token’s bonding curve on-chain, where anyone can check it. So the creator fees a token earns accrue to its own vaults, apart from every other token’s, and they are earmarked for the church the token is named for. The launcher does not receive them and cannot redirect them.

Every 10 minutes HolyPad’s engine checks each token. Once a token’s fees are worth at least $5, it sweeps the creator vault into the token’s fee wallet and forwards everything above a small reserve (0.005 SOL, so the wallet can always pay for its next sweep) to the token’s destination, recording the amount, the address and the transaction against that token. The destination is decided the same way before every sweep: the address the token’s church registered with HolyPad, if that registration was signed from the wallet itself and approved by HolyPad’s operator with a second signature that still verifies (for churches); else the address the church publishes on its own site, if the launch was bound to that church in the directory; else the HolyPad donation wallet, whose address is read from the server’s environment at signing time. The engine can send nowhere else: nothing in the database alone, and nothing in a request, can change where the money goes. The server holds each token’s fee wallet key, encrypted, and builds only two transactions with it, the sweep and the forward. It never holds the donation wallet’s key, the operator’s key or any church’s key.

The engine is live. Every forward is recorded against its token with its transaction signature, and the donations page shows what the donation wallet holds, read from the chain.

The donation wallet is Z7paCrX6ihkmzAPTBxAVBXj6fQotFfMbJ79XYyU9Zxf (Solscan). It is where every token’s fees go unless its church registered or publishes an address, and each token’s total is recorded separately on the way in.

By hand, token by token, at least once every three months. Each token’s fees are earmarked for the church it is named for: HolyPad donates that token’s total to that church, and the ledger entry names the token. A token bound to a church that registered or publishes its own address needs no such step: each sweep is the payment, and it is on the token’s page with its transaction. For every other token, HolyPad decides when and how it is sent. It does not decide whether: SOL that reaches the donation wallet is committed to churches, and none of it goes to HolyPad’s own use, to launchers or to anyone holding a token.

A donation is sent through an established crypto-giving rail the church already uses (Engiven or The Giving Block), through a processor that pays the church in dollars (Crypto for Charity or Every.org), or directly to the church’s own wallet. Processor fees of 0 to 6% and network fees come out on the way, so the church receives slightly less than leaves the wallet. Each entry on the donations page records how it was sent.

If a church declines a donation or cannot be paid, that token’s money goes to another church, of HolyPad’s choosing. It does not come back to HolyPad.

Each donation is published on the donations page with the date, the church, the token whose fees it came from, the amount, how it was sent and a link that proves it. A donation that is not listed there has not been made.

HolyPad is the donor of record. Any receipt a rail issues is HolyPad’s. Launching, buying, holding or trading a token earns no receipt and no tax deduction for anyone else. Naming a church in a launch earmarks the token’s fees for that church. It is not a contract: HolyPad decides when and how the donation is sent, and if the church cannot be paid or declines, the money goes to another church. It gives no one a claim on the money, and a church that receives a donation has not endorsed HolyPad or any token.

For a church wondering how a donation in SOL reaches it. This is a description drawn from each rail’s own documentation, not legal or tax advice; fees are as published and can change.

A church in the United States is a 501(c)(3) automatically, without applying (IRS), and the IRS treats cryptocurrency as property (IRS FAQ), so a church can accept SOL the way it accepts any non-cash gift. Most churches do it through a processor that converts to dollars:

• Engiven. A crypto giving processor built for churches, switched on inside Tithe.ly, Pushpay and Subsplash. Gifts are converted to dollars automatically. The church pays a 4% service fee on gifts received on the standard plan, or 3% plus $1,500 a year on the premium plan (Engiven). SOL is on its list (Engiven: Solana).
• The Giving Block. Churches get a public giving page and receive dollars or hold the crypto (packages). The minimum for SOL is 0.005 SOL (FAQ). Its per-gift fee is not published; a Donorbox integration document cites 3.95% (Donorbox), and its own packages page lists an annual subscription.
• Every.org. A 501(c)(3) giving platform. Crypto is converted to dollars immediately and the church receives a grant (how it works). No platform fee for givers; a 1% broker fee on the sale plus the network fee, and a 1.5% disbursement fee unless the church has linked a bank account (fees). SOL is listed (supported coins). A church missing from its IRS-derived list can be added by email (which nonprofits).
• Crypto for Charity. Run by the FreeWill Impact Fund, a 501(c)(3). The church needs no setup: the gift is sent to a one-time address and the fund converts it and grants the dollars (how it works). No added fee beyond the exchange’s conversion fee; gifts over $100 are paid by ACH within one to two business days, smaller ones monthly (FreeWill). Its pages do not name SOL, so HolyPad confirms support before a first send. The receipt comes from the fund, not the church.
• Directly. A church can receive SOL in its own wallet and sell it through an exchange account in its name; most churches sell on receipt. Before accepting, it should adopt a written gift acceptance policy that covers crypto (Church Law & Tax, Every.org). For a gift of $250 or more it gives the donor a written acknowledgment describing, but not valuing, the gift (IRS), and if it sells the gift within three years it files Form 8282 (IRS).

Whichever rail, HolyPad sends native SOL: every rail above except Crypto for Charity names SOL, none documents USDC on Solana, and The Giving Block warns that coins sent on an unsupported network are lost (FAQ).

pump.fun also offers its own charity option, routed through donate.gg, a for-profit processor that charges a flat 10% (pump.fun, donate.gg terms). HolyPad does not use it. It gives through the rails above, at 0 to 6%, to churches that have agreed to receive.

The churches, dioceses, Catholic charities and ministries this research found accepting crypto on their own giving pages are listed on the churches page; a listing there states that one fact only and is not consent to a token, an endorsement or a partnership.

A church can have sweeps sent straight to a wallet it controls. Register a Solana address on the registration page: fill in the church, its website and a contact, connect the wallet the address belongs to, and sign a short message from it. Once HolyPad has approved the registration, every sweep of every token bound to that church leaves the token’s fee wallet for the registered address, on-chain, with a record against the token, and HolyPad never holds it. Until then, and for every church that has neither registered nor published an address, sweeps go to the HolyPad donation wallet and HolyPad donates each token’s total by hand.

Why it is not automatic for every church already. The directory lists churches that accept crypto on their own giving pages, but almost all of them do so through a processor, and a processor generates a one-time address for each gift. There is no static address to copy, so HolyPad cannot register a church from its giving page on its own. A church that registers gives HolyPad an address that stays the same, and proves it holds the key.

What is verified. Two signatures, and only those. The church’s wallet signs a message naming the church, its location, its website and the address; that proves whoever registered controls the wallet. The contact email must be at the website’s own domain, and HolyPad may write to it, read the site or ask for more before deciding. HolyPad’s operator then approves by signing a second message, from the HolyPad operator wallet, naming the church, the address and the registration. The engine uses a registered address only while both messages rebuild exactly from the stored registration and both signatures verify against the wallet that registered and an operator wallet named in the server’s environment. The server holds neither key. Someone with access to the database could insert, edit or flip a registration; without the church’s key and the operator’s key nothing new they write verifies, and the engine sends to the HolyPad donation wallet instead. A revoked approval’s old signature is kept only as history, so the durable way to close a church’s routing is to approve its replacement. An address must be a plain wallet: if it is owned by a program, the engine skips the sweep and records why.

Revocation. A church can revoke its registration at any time by writing to HolyPad, and HolyPad may decline or revoke any registration at its discretion. A revoked registration takes effect on the next sweep: tokens bound to the church go back to the address it publishes on its own site, if any, else to the HolyPad donation wallet. A church can register a new address; approving it revokes the old one in the same step, so one church has one address at a time. The churches page shows the address in force and the date it was approved.

What registering is not. It is the church’s consent to receive donations at that address, and nothing else. It is not consent to, or an endorsement of, any token: a token bound to a registered church still says the church has not consented to it until the church confirms that token in writing, separately (the consent rule). What arrives is HolyPad’s own giving out of its creator-fee income; HolyPad is the donor of record. Buying, holding or trading a token is not a donation, and buyers get no receipt or deduction. The pump.fun creator fee is currently 0.30% of trading volume on the bonding curve, less after graduation; pump.fun does not guarantee any fee is charged or distributed, and a token can go to zero. The church’s name, location, website and address are public once approved; the contact name, role and email are seen by HolyPad only.

Anyone can launch a token named after any church, and HolyPad does not check. So every token page carries one of two statements, in plain view, and never a church’s name as if it had agreed:

• “This church has consented in writing to this token.” Shown only after the church has confirmed to HolyPad, in writing, that it agrees to the token carrying its name. HolyPad sets it; a launcher cannot.
• “This church has not consented to or endorsed this token. Anyone can launch a token named after any church.” The default, on every token page until the first applies.

Consent means the church agreed to its name on the token. It does not mean the church endorses the token, partnered with HolyPad or asked for a launch, and it is not a promise of a donation: a token’s fees are earmarked for the church it is named for, HolyPad donates that token’s total by hand when it can, and if the church cannot be paid or declines, the money goes to another church.

The rule is written down because the law is. California, for one, makes it a violation to represent that contributions will go to a charity that has not consented in writing (Gov. Code 12599.6). HolyPad applies it everywhere. A church that consents should not urge its congregation to buy the token: the IRS treats that as advertising rather than acknowledgment (IRS).

A church that wants to consent, to correct how it is named, or to have its name taken off a token can contact HolyPad.

Streaming is optional at every point. A pastor, a launcher or anyone with a launch can go live on camera; nothing about a launch requires it. In the control room a launcher can turn a camera on before creating the token; nothing starts on its own. Afterwards the wallet that created a token can go live on that token’s page at any time, and only that wallet can. A stream appears on the token page while it is on air.

Two extras exist once a camera is on. A still frame can be captured from the stream and hashed. With a frame captured, the launching wallet can sign a plain-text pledge naming the token, the wallet and the hash of that frame. Both are shown on the token page, and anyone can check the signature against the wallet. Neither is required to launch, and neither changes where the fees go.

If you go live, you consent to your stream, your voice, any frame you capture, your wallet address and your pledge being public and permanently associated with the token. If you never turn a camera on, none of that exists. Your wallet address is public either way: it is on-chain.

• Nobody is vetted. Anyone with a wallet can launch a token named after any church. HolyPad does not check who they are or whether they have any connection to that church, and there is no verification badge. A stream, when there is one, is a face, not a guarantee.
• No church is behind any token unless its token page says the church consented in writing, and even then consent is not endorsement. A donation to a church does not change that.
• Buying a token is not a donation. It is a purchase of a token on pump.fun. It is not a tithe, an offering or a gift to any church; it earns no receipt and no tax deduction; and it gives no claim on the token’s fee wallet, on the donation wallet, on any church, on HolyPad or on anything else.
• Tokens can go to zero. A token launched here is a pump.fun token like any other, a digital collectible that can lose all of its value. HolyPad does nothing to support any token’s price. Meme coin holders are not protected by the federal securities laws (SEC staff statement).
• The creator fee is not guaranteed. pump.fun does not guarantee that any creator fee is charged or distributed; the share falls at higher market caps and is zero in some pools; and its terms allow control of a token’s creator fee to change hands through a community takeover.
• HolyPad decides which church and when. HolyPad is a for-profit launchpad that gives away the creator fees of the tokens launched on it, not a charity, a nonprofit or a foundation. A token’s fees are earmarked for the church it is named for and HolyPad donates that token’s total to that church by hand; when and how is HolyPad’s decision alone, if the church cannot be paid or declines the money goes to another church, and HolyPad makes no promise to anyone about any particular church.
• You are trusting HolyPad to sweep and to donate. The server holds each token’s fee wallet key, encrypted, and uses it only to sweep that token’s fees and forward them to the token’s destination: the address its church registered with HolyPad or publishes on its own site, when both registration signatures still verify, or else the donation wallet, whose address is fixed in the server’s environment. The server never holds the donation wallet’s, the operator’s or any church’s key. What you can check: the creator on any token’s bonding curve, that fee wallet and its vaults on-chain, the donation wallet or the church’s registered address and its two signatures on the churches page, and the ledger on the donations page, where every donation carries proof.
• Not available where pump.fun restricts. pump.fun’s terms exclude certain countries and sanctioned persons (terms). If they exclude you, HolyPad is not available to you either.
• You sign every transaction. HolyPad never holds your wallet’s keys or your tokens. You are responsible for compliance with the laws of your jurisdiction. Nothing on this site is legal, tax or investment advice.