Geyser
Geyser is where Bitcoin fundraising meets the open social graph: creators launch projects, receive direct Lightning or on-chain support, sell rewards, publish updates, connect Nostr identity and let funders turn contributions into public Nostr notes.
What Geyser really is
Geyser is a crowdfunding and fundraising platform built around Bitcoin projects, creator work, humanitarian causes, rewards and community support. Its live homepage describes the product as helping people launch new Bitcoin project ideas and fund humanitarian causes worldwide through transparent crowdfunding. The GitHub organization calls it a lightning-native bitcoin crowdfunding platform for creators, while the main app repository says Geyser is a bitcoin and Nostr native crowdfunding platform where project ideas can be funded with the support of global communities.
That wording matters. Geyser is not a wallet app in the way Zeus, Alby Hub or Phoenix are wallet apps. It is not a social client in the way Damus, Coracle or Primal are social clients. It is a funding surface. A creator uses it to make a project page, tell a story, set a funding mechanism, connect a receiving wallet, publish updates, offer rewards, invite ambassadors, apply for funds or receive grants. A contributor uses it to discover a project, send money, buy a reward, leave a comment, appear publicly or stay anonymous.
Its Nostr relevance comes from the way social identity and funding are joined. Geyser supports NIP-07 login, Nostr-linked user accounts, project npubs, public Nostr share posts, NWC project wallets and a live NIP-05 document for `geyser@geyser.fund`. That does not make every contribution a Nostr zap. It means Geyser treats Nostr as part of discovery, identity and wallet connectivity around a Bitcoin fundraising workflow.
The public product surface
A normal reader sees Geyser as a project marketplace for funding. The product is organized around project pages, launch paths, contribution forms, rewards, updates, profiles, impact funds and discovery. The Guide explains that contributors can donate to projects or purchase products and rewards from project pages. It also says Geyser supports multiple payment methods, including Lightning and on-chain payments, while never holding or controlling contributor funds in the normal contribution flow.
The launch side is built for creators who need more than a payment link. Geyser asks for a story, a project, a wallet, visuals and a launch mode. Project features include goals, posts, rewards, affiliates, insights, delivery and accounting tools. That is why Geyser belongs under Funding rather than a narrower wallet shelf. The hard job is not only generating an invoice. It is giving a project enough context, trust signals, updates and community surface for people to decide whether they should fund it.
There are two broad funding shapes to keep in mind. Open Fundraisers are direct, peer-to-peer and final, with creators receiving funds immediately. All-or-Nothing campaigns introduce a conditional goal: the creator receives the funds when the goal is reached, and if it is not reached, contributors need the refund path. That distinction changes how a reader should test a campaign before sending serious money.
Why the Bitcoin rail matters
Geyser exists because conventional crowdfunding is narrower than the internet. Traditional platforms often operate inside a limited set of banking jurisdictions, require platform accounts, impose payment processor rules and can make cross-border support awkward. Geyser's README frames the alternative as an open creator economy built on Bitcoin, Lightning and Nostr. The point is not only lower fees. The point is that a creator in one country can receive support from people elsewhere without waiting for the usual card and bank account stack to become friendly.
Lightning is the default mental model because it makes small contributions and repeated support practical. The Guide tells contributors they can fund through a browser wallet such as Alby, scan or copy a Lightning invoice, or use on-chain instructions where relevant. The public app also creates LNURL pay QR flows for project pages, so a project can be shared as a funding target rather than only as a website link.
On-chain and fiat paths are part of the real product too. The fee docs mention on-chain swaps through Boltz and credit-card swaps through Banxa. The codebase contains contribution payment details for Lightning, on-chain swaps, fiat-to-Lightning swaps and related refund metadata. That is useful for reach, but it adds moving pieces. A user should know which payment rail was used, which fees applied, what refund data must be kept, and whether a card processor or swap provider sits in the path.
Fees are flexible, not invisible
Geyser's current fee documentation says platform fees range from 0% to 5% and can go higher if a creator opts into extra marketing support. It separates Geyser creator fees from contributor-side costs. The standard base fee is 5% when Geyser runs the wallet arrangement, while creators who run their own node or wallet setup can reduce Geyser's platform commission to 0%. That is a meaningful trade: more control can lower platform cost, but it increases the creator's operational responsibility.
The fee page also explains payment method costs. Lightning has near-zero routing fees. On-chain contributions can involve a Boltz swap fee plus mempool fees. Credit-card payments can involve Banxa fees for the swap into Lightning. Optional promotion network support can add a 10% fee when the creator switches that channel on. For a contributor, this means the project page is not the whole fee story. You need to look at the payment method and any campaign options.
A careful creator should estimate the net funds needed, not only the headline goal. If a project needs 10 million sats after fees, shipping and reward fulfillment, the public goal should reflect the full cost. A careful contributor should look for clear budgeting, delivery promises, reward limits and update history. Geyser can make funding easier, but it cannot make a weak project plan strong.
Nostr login lowers identity friction
Geyser supports several account paths, and Nostr is one of them. The `ConnectWithNostr` component appears only when `window.nostr` exists, meaning the browser has a NIP-07-compatible extension or signer. The login hook asks the auth endpoint for an event, inserts the user's pubkey, calculates the event hash with `nostr-tools`, asks the extension to sign the event and sends the signed event back as a token to the auth endpoint.
This is the right shape for web login with Nostr. The user does not paste an nsec into Geyser. The signer supplies a public key and signs an auth challenge. For a creator or funder, that means a Geyser profile can connect to a public Nostr identity without turning the crowdfunding site into a key custodian. The security still depends on the signer, browser and user choices, but the application does not need the private key itself.
The practical limit is important. A NIP-07 login proves control of a key to the service. It does not prove the project is honest, the fundraiser is legally safe, or the creator will deliver rewards. It is identity plumbing, not trust itself. Geyser is strongest when Nostr identity is combined with project history, funding comments, social proof, updates, public npubs and off-platform verification.
Project npubs turn pages into social objects
The codebase exposes Nostr keys as part of project data. The generated GraphQL types include `NostrKeys`, a public npub and public hex key, and project query fragments include those keys. The project header can show a modal with the project's Lightning Address and Nostr npub. The copy in that modal describes the npub as the project's unique identifier on the censorship-resistant, decentralized Nostr social network.
That changes how a Geyser project can circulate. A project is not only a URL on a crowdfunding site. It can have a Nostr public key that appears inside notes, share text and identity displays. The `useNostrPostForProject` hook builds a kind 1 Nostr note that references the project npub, optionally references the creator npub, tags Geyser's public key, adds `geyser` and `crowdfunding` tags and identifies the client as Geyser.
For readers, this is useful because crowdfunding needs portable reputation. If a project can be discussed through Nostr notes, funded through a page, and referenced through an npub, it becomes easier for supporters to talk about it outside the Geyser interface. The caution is that project npubs need to be verified in context. A public key by itself is not a legal identity, a delivery guarantee or a proof that a project page is still under the same operator.
Posting to Nostr is explicit
Geyser does not silently publish every user action as a Nostr note. The project header contains a Post on Nostr action that is shown only when the project has a Nostr public key and the browser has a NIP-07 signer. When the user clicks it, the app builds a note, asks the signer to sign it, and then calls a GraphQL mutation that publishes the signed event.
Funding success has a similar pattern. The contribution-success hook can create a kind 1 note saying the user zapped a number of sats into a Geyser project. It tags Geyser, the project, and sometimes the creator. It also adds tags for `geyser`, `crowdfunding` and `zap`. This is good product design because funding can become social proof when the contributor chooses to publish it, but it is not forced onto everyone.
This also clarifies a common confusion. Geyser contributions are not automatically equivalent to NIP-57 zap receipts. In the code paths inspected here, Nostr sharing is a signed note created around a project or a funding success. The payment settlement itself is handled through Geyser's contribution and wallet flows. If a user wants public Nostr proof, they should inspect what event was signed, where it was published and whether it includes the expected project key.
NIP-05 identity is live
Geyser has a live NIP-05 response for `geyser@geyser.fund`. The checked endpoint `https://geyser.fund/.well-known/nostr.json?name=geyser` maps the name `geyser` to the public key `b6dcdddf86675287d1a4e8620d92aa905c258d850bf8cc923d39df1edfee5ee7` and returns relay hints including `wss://nos.lol/`, `wss://purplepag.es/`, `wss://relay.pleb.to/` and `wss://relay.primal.net/` among others. A request without a name returned a 400 response during the check, so the name-specific request is the useful one to test.
The same check found no live Lightning Address at `https://geyser.fund/.well-known/lnurlp/geyser`; it returned 404. That is worth saying plainly because the domain can verify a Nostr name without also serving a public LNURL-pay address for the same local part. Readers should not infer a live payment address from a live NIP-05 name.
For a funder, NIP-05 is one piece of verification. It says the domain currently claims that Nostr public key for that name. It does not verify a specific project page, a creator's legal identity, or the wallet connected to a campaign. For a creator, it is still valuable because it gives supporters a domain-backed Nostr identity they can compare across clients.
Wallet setup has two paths
The creator wallet form is one of the most important parts of Geyser. In the project creation code, `useWalletForm` offers two connection options: Lightning Address and NWC. A Lightning Address is validated as an email-formatted address, checked through the `lightningAddressVerify` query, and rejected if it ends with `@geyser.fund` when used as a custom receiving address. If it passes, it becomes the wallet connection details for that project.
The NWC path accepts a `nostr+walletconnect://...` value and writes it into `nwcConnectionDetailsInput`. The shared `WalletConnectionForm` describes Nostr Wallet Connect as a protocol that uses Nostr to connect web apps with Lightning wallets and links to `nwc.dev`. The UI highlights Alby Hub as a featured NWC wallet. This is a real NWC integration, not just a category label in a directory.
Both paths carry risk. Lightning Address is easier for creators who want a simple receiving address, but it depends on the wallet provider and validation limits. NWC is more powerful because it can let Geyser create and track invoices through a wallet service, but the connection string is a credential. A creator should use tight permissions, revocable connections and a wallet setup that matches campaign size.
NWC is backend permission, not magic
Nostr Wallet Connect lets an app and a wallet coordinate through Nostr relays. In Geyser's case, the practical question is whether the project wallet can reliably receive contributions and expose enough state for Geyser to track them. The generated GraphQL schema includes private NWC connection details, NWC create and update inputs, and wallet fragments that can return `nwcUrl` for the project wallet connection.
That makes NWC an operational backend choice. A creator who enters an NWC URL is authorizing Geyser to use a wallet connection. The exact capabilities depend on the wallet that issued the URL. Some NWC grants are receive-focused. Others may expose broader methods. The article cannot safely assume every NWC wallet behaves the same. The responsible check is to inspect the wallet's permissions, budgets, method list, expiration and revocation controls before connecting it to a live campaign.
For high-trust fundraising, test NWC with a low-value project first. Create a small contribution, watch invoice creation, confirm settlement, check how Geyser records it, restart the session, and verify that old invoices can still be looked up. Then revoke the connection and confirm that Geyser can no longer use it. A crowdfunding platform is exactly where stale wallet permissions should not be left floating around.
Rewards make funding feel like commerce
Geyser is not limited to donation buttons. The Guide describes products and rewards, while the codebase has project reward types, costs, stock, sold counts, reward images and order state. Project features include reward creation and delivery/accounting tools. That means some campaigns are closer to preorder commerce than pure donation.
This matters because rewards change contributor expectations. A 5,000 sat thank-you boost and a 500,000 sat hardware preorder are not the same risk. The first is support. The second introduces fulfillment, shipping, taxes, stock limits, delays and customer support. Geyser can display rewards and help track delivery, but the creator still bears the operational burden of delivering what was promised.
For readers, the rule is simple: read the reward terms like a buyer, not only like a supporter. Check whether the creator has shipped before, whether shipping regions are clear, whether digital rewards are realistic, whether the campaign has recent updates, and whether the refund path applies. Bitcoin settlement can be fast; product delivery can still be slow.
Impact Funds are curated funding pools
The current Guide redirects older grant language toward Impact Funds. It describes Impact Funds as a way to move bitcoin from passive holding into active adoption by pooling capital and distributing it continuously to initiatives that are building the future of Bitcoin. It lists four live Impact Funds: Latin America, Culture, Education and Circular Economies. It also notes that there is currently no dedicated open-source development Impact Fund live.
The model is different from one person funding one project. Sponsors and community members contribute to a themed fund. Builders apply to the fund that matches their initiative. Applications are reviewed for alignment, feasibility and impact. Selected initiatives receive recurring distributions. That creates a more curated funding layer on top of the same broad platform mechanics.
Geyser also has a history of Grants. The Guide describes board voting and community voting, including a one-satoshi-one-vote model and an incremental voting model. Past grant rounds included education, gaming, film and earlier creator/builder categories. For a Nostr reader, this matters because Geyser is not only a payment page builder. It is trying to become a funding coordination layer for Bitcoin communities.
Launch modes change expectations
The current launch-mode docs list Starter, Growth and Pro launch options with different prices and support levels. Starter is a do-it-yourself launch with platform discovery. Growth adds a front-page spotlight, newsletter placement, social media post and one-time project feedback. Pro adds direct launch strategy, dedicated support and access to Geyser's creator and media network. These launch modes are product packaging, not protocol behavior.
The distinction matters for trust. A project that appears in a promotion slot is not automatically safer than a project that did not buy promotion. It may simply have chosen a launch package. Likewise, a self-launched project is not automatically weak. Contributors should treat launch visibility as a discovery signal, not due diligence.
Creators should be just as careful. Promotion can bring attention before the project is ready. If the wallet is untested, rewards are vague, budget is thin or the story is unclear, more visibility can amplify confusion. A good Geyser launch starts with a realistic goal, a working wallet, a plain-language budget, concrete milestones and update discipline.
The open-source app is active
The main public repository is `geyserfund/geyser-app`. On June 13, 2026, the GitHub API described it as TypeScript, GPL-3.0 licensed, created on August 31, 2021, with the default branch `staging`, 61 stars, 18 forks, 8 open issues and a push on June 12, 2026. Recent commits included fixes around All-or-Nothing campaign balance fallback and project funding review comments. That is a live product codebase, not an abandoned showcase.
The app uses React, TypeScript, Chakra UI, Apollo GraphQL, React Router, Sentry, `nostr-tools`, WebLN, Boltz-related libraries and payment-provider integrations. The repository README still contains generic template residue in its Built With section, but the code itself shows a mature application with routes, generated GraphQL types, project funding flows, reward logic, wallet setup, auth, profile surfaces and testing.
Open source does not mean every backend service is exposed in the same repository. The front-end points to an API endpoint and generated GraphQL schema. That is normal for a hosted platform. It means an auditor can study a lot of user-facing behavior, wallet form logic and Nostr signing flows, but still needs to distinguish public front-end code from server-side policy, moderation, fraud handling and operational controls.
Where the risks sit
The first risk is project truth. Geyser can show a page, comments, updates, funding amount, rewards and identity links. It cannot guarantee that every creator will deliver. Crowdfunding always carries execution risk. Bitcoin settlement can make that risk feel sharper because payments are often final or conditional through a specific campaign mechanism rather than reversible card transactions.
The second risk is wallet configuration. A bad Lightning Address, stale NWC credential, wrong wallet limits, insufficient liquidity, expired connection or broad spending permission can turn a good campaign into a support problem. Creators should test small payments before launch and contributors should avoid sending large amounts to campaigns whose wallet or refund behavior they have not inspected.
The third risk is privacy and public signaling. Logged-in contributions can display a profile and connected accounts; anonymous contributions are possible. Public comments, Nostr notes and funding-success posts can be useful social proof, but they also reveal behavior. Before signing a Nostr post or leaving a comment, a contributor should decide whether the link between pubkey, project and amount should be public.
The fourth risk is jurisdiction and compliance. Geyser's FAQ says most countries can use the platform, but verification thresholds can apply when a creator raises over certain amounts, and fiat or card paths introduce partners with their own rules. A humanitarian fundraiser, hardware campaign or community project may also have local legal responsibilities outside Geyser's product UI.
How to test Geyser before relying on it
If you are a contributor, start small. Choose a project where you understand the creator, send a tiny Lightning contribution, decide whether to appear publicly or anonymously, and check how the contribution appears on the project page. If the campaign is All-or-Nothing or uses on-chain refund mechanics, read the refund instructions before you pay. If the project asks you to buy a reward, read the delivery terms as carefully as you would on any other store.
If you are a creator, test the entire route before announcing. Connect a Lightning Address or NWC wallet, verify limits, make a small self-contribution, check settlement, publish a post, copy the Lightning Address, test the project npub modal, try the Post on Nostr action with a dedicated signer, and confirm that launch fees, Geyser fees, optional promotion fees and payment-rail fees are represented in your budget.
If you are a builder, read the source paths rather than the pitch. Start with the NIP-07 login hook, the `WalletConnectionForm`, `useWalletForm`, project wallet mutations, LNURL pay share components, Nostr project post hook and funding-success post hook. Then compare them with NIP-05, NIP-07, NIP-19, NIP-47 and NIP-57. The useful lesson is how a real crowdfunding product stitches ordinary web app state to Nostr identity and Bitcoin payment rails.
Who Geyser fits
Geyser fits Bitcoin creators, educators, open-source projects, circular economy groups, event organizers, artists, humanitarian efforts and early product teams that want a public funding page without asking supporters to use a traditional crowdfunding platform. It is especially useful when the audience already understands Lightning, sats, Nostr identity and public project updates.
It is less ideal when the project needs the consumer protection, chargeback behavior, tax tooling or compliance workflows of a mainstream platform. Geyser can support rewards and project accounting, but it does not remove the need for business discipline. A creator selling physical goods still needs shipping, support and records. A donor supporting a cause still needs to judge legitimacy.
For Nostr readers, Geyser matters because it makes funding social without making it purely social. The funding page remains a structured project surface. The wallet remains a payment backend. Nostr adds login, identity, npubs, sharing and NWC connectivity. That combination is closer to a real creator economy than a simple tip button.
Closeout
Geyser is one of the clearest examples of Nostr moving into practical Bitcoin commerce without becoming a social feed. It gives creators a public campaign page, lets supporters fund with Bitcoin rails, supports rewards and updates, and then uses Nostr where it helps: sign-in, identity, project references, public posts and wallet connectivity through NWC.
The best way to read it is neither as a miracle of decentralization nor as just another hosted website. It is a hybrid. The front-end and much of the product logic are open source. The platform operates a hosted service. Payments can be direct to creator wallets, but wallet setup and campaign type determine the trust model. Nostr identity can make projects more portable, but it does not replace due diligence.
Use Geyser with the same clarity it asks from projects. Know which wallet receives the funds. Know whether the campaign is open or conditional. Know what fee path applies. Know whether you are posting publicly to Nostr. Know how refunds work before you need one. If those pieces are visible and tested, Geyser becomes a serious funding layer for Bitcoin and Nostr builders.
Sources worth opening
Start with the live site and Geyser Guide, then read the GitHub repository and the exact code paths for NIP-07 login, Nostr posting, project npubs, LNURL pay, wallet setup, NWC connection details, fees and Impact Funds. Then compare those implementation details with NIP-05, NIP-07, NIP-19, NIP-47, NIP-57, NIP-98 and the broader NWC documentation before relying on Geyser for a real campaign.
- Geyser official site
- Geyser Guide
- Geyser Guide: Getting started
- Geyser Guide: Contribute on Geyser
- Geyser Guide: Launch a project
- Geyser Guide: Project features
- Geyser Guide: Connect your wallet
- Geyser Guide: Launch modes
- Geyser Guide: FAQ
- Geyser Guide: Fees
- Geyser Guide: Lightning wallets
- Geyser Guide: Countries on Geyser
- Geyser Guide: Impact Funds
- Geyser Guide: Intro to Geyser Grants
- Geyser Guide: Evaluation process
- Geyser Guide: Past grants
- Geyser GitHub organization
- Geyser app repository
- Geyser app README
- Geyser app package metadata
- Geyser app environment example
- Geyser NIP-07 login hook
- Geyser NIP-07 helper
- Geyser Connect with Nostr component
- Geyser project Nostr post hook
- Geyser Post on Nostr component
- Geyser funding success Nostr hook
- Geyser Lightning Address and npub modal
- Geyser npub display component
- Geyser Lightning funding section
- Geyser Lightning Address component
- Geyser share contribution QR view
- Geyser project wallet form hook
- Geyser wallet connection form
- Geyser project wallet mutations
- Geyser project wallet fragments
- Geyser project wallet API hook
- Geyser live NIP-05 response
- getAlby awesome-nwc: Geyser listing
- Nostr Wallet Connect official site
- Nostr NIP-05 identifiers
- Nostr NIP-07 web signer capability
- Nostr NIP-19 bech32 entities
- Nostr NIP-47 Wallet Connect
- Nostr NIP-57 Lightning zaps
- Nostr NIP-98 HTTP auth
- Bitcoin Magazine: Geyser NWC grant
- Forbes: Geyser and Lightning crowdfunding
