HCB: The Open Source Fiscal Sponsorship Platform That Powers Hack Club's Financial Program

What HCB Is: Fiscal Sponsorship as a Product

Fiscal sponsorship lets a small organization operate under the legal and tax umbrella of an established nonprofit, receiving tax-deductible donations without incorporating separately. HCB is the platform Hack Club built to run this program for high schoolers. According to the README, it provides a 501(c)(3) status-backed restricted fund for hackathons, Hack Clubs, and robotics teams.

The README describes it as "open source, safe, and easy-to-use." The source is public on GitHub under the AGPL-3.0 license, and Hack Club runs their own fiscal sponsorship program on this exact codebase, which means the production system and the public repository are the same software.

The target users of the platform (not the codebase) are high schoolers running technology events or clubs who need a legal entity and a bank account without the overhead of founding a nonprofit. Developers interested in the codebase are people who want to contribute to or study a real-world financial application handling real money for real organizations.

How the Restricted Fund Model Works in the Codebase

A restricted fund in fiscal sponsorship means that money donated to a project goes into the fiscal sponsor's bank account, tagged to that project's fund. The project can spend from their fund through the sponsor's systems, but they do not hold the money directly.

In HCB's case, Hack Club acts as the fiscal sponsor and holds the funds. The HCB platform provides the interface for each sponsored organization to see their balance, issue virtual and physical cards, send payments, and receive donations. The README does not detail the internal financial model in the visible text, but the application's scope is clear: it handles the financial operations for multiple sponsored organizations under one legal entity.

From the technical side, the Stripe dependency in package.json is the primary payment processing integration. AppSignal (the @appsignal JavaScript packages) handles error monitoring. The application uses Tiptap for rich text editing, which likely powers invoice descriptions or announcement fields. Alpine.js and Hotwire/Stimulus provide the interactive UI without a full single-page app framework.

Running HCB in Development

The README says HCB supports three development setups: GitHub Codespaces, Docker, and a native setup. Detailed instructions live in the dev-docs/ folder at dev-docs/development.md. The Docker path is the most reproducible starting point.

The docker-compose.yml defines three services: PostgreSQL 15.13, Redis, and the web application. Start the full stack with:

docker compose up

The web container binds to 127.0.0.1:3000 and connects to Redis at redis://redis:6379. The application reads environment variables from .env.development (copied from .env.development.example). The Dockerfile uses Ruby 3.4.9 and Node.js 24 as the base environment.

The default Docker command runs foreman with Procfile.dev to start the development server:

bundle exec foreman start -f Procfile.dev -m all=1,stripe=0

The stripe=0 argument disables the Stripe webhook listener by default in development. The Procfile.dev controls the full set of processes that run together in development.

For Codespaces, the .devcontainer/ folder in the repository provides the container definition. Contributors who prefer native setup should follow the dev-docs/development.md instructions.

Technology Stack: Rails, PostgreSQL, and the Frontend

HCB is a Ruby on Rails application running Ruby 3.4.9. The development Dockerfile installs bundler 2.5.17 explicitly. Background jobs run via a separate process managed by foreman. The application requires Redis alongside PostgreSQL, suggesting it uses Redis for caching, job queues, or ActionCable.

The frontend is built with Webpack. The package.json lists Hotwire (Turbo and Stimulus) as the primary interactivity layer, with Alpine.js for additional client-side behavior. The package name in package.json is @hackclub/bank, the original name of the product before it was rebranded to HCB. Node.js 24 is required.

The application uses Stripe for payment processing (@stripe/stripe-js is in the dependencies). AppSignal provides JavaScript error monitoring and performance tracking. The codebase includes Rubocop for Ruby linting, ESLint for JavaScript, and SimpleCov for code coverage. The test suite uses RSpec (the spec/ directory and .rspec configuration).

Security vulnerabilities are handled through a dedicated security email and bounty program at security.hackclub.com. The README asks that vulnerabilities be reported to [email protected] rather than filed as public issues.

AGPL-3.0 License: What It Means for Forks and Deployments

The AGPL-3.0 (GNU Affero General Public License version 3) is a strong copyleft license with a network use clause. Under AGPL-3.0, if you modify HCB and run it as a service (users interact with it over a network), you must make the modified source code available to those users. This extends the GPL's requirements to hosted software, closing the so-called application service provider loophole.

For a fiscal sponsorship platform, the implications are concrete: any organization that forks HCB and deploys it to serve their own sponsored organizations must publish their modifications. This is different from the MIT or Apache-2.0 licenses used by many open source projects, where hosting a modified version does not require disclosure.

This license choice is intentional. It keeps the software ecosystem open and prevents proprietary forks from competing without contribution. Teams evaluating HCB as a base for their own fiscal sponsorship product should plan for source disclosure as a legal requirement, not a choice.

Contributing and How HCB Compares to Open Collective

The README directs contributors to dev-docs/development.md for setup and to the #hcb-dev channel on the Hack Club Slack for support. All contributors must follow the Hack Club Code of Conduct and contributing guidelines. The README explicitly invites contributions.

For the development workflow: the codebase includes GitHub Actions in .github/, Rubocop for linting, RSpec for tests, and runbooks in the runbooks/ directory for operational procedures. There are also docs/ and dev-docs/ directories with further documentation.

Open Collective is a comparable fiscal sponsorship platform that operates globally and also makes its source available. The key differences are audience and scope: Open Collective serves open source projects and communities of many kinds worldwide, operates its own fiscal hosting network, and provides a public ledger by default. HCB is specifically built for Hack Club's program serving US-based high school clubs and hackathons under a single sponsoring nonprofit. Teams building on Open Collective can work with multiple fiscal hosts globally; teams on HCB are working within the Hack Club program's legal structure. Anyone looking to run a competing fiscal sponsorship platform in another country would need to adapt the 501(c)(3)-specific logic for their jurisdiction's nonprofit laws.

The last push to the repository was on 2026-09-27. The project is not archived and shows consistent daily activity. No GitHub releases are tagged; the codebase is continuously deployed from main.

Editorial conclusion

HCB as a codebase is most useful to developers who want to understand, audit, or extend a production fiscal sponsorship platform that is actively used at scale. The AGPL-3.0 license means any deployment with modifications must publish its source. Organizations outside the US considering a fork should note that the 501(c)(3) tax-exemption model is US-specific and requires legal adaptation for other jurisdictions. Review the dev-docs/ folder and the #hcb-dev Slack channel before contributing to understand the current development priorities.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository