Inspiration

Sats-Stamp: Putting a Small Bitcoin Bond Between Maintainers and Spam

Inspiration

Open-source maintainers are facing a growing problem: spam, low-effort contributions, and AI-generated pull requests that consume valuable review time. The root cause is simple—the cost of submitting thousands of low-quality contributions is effectively zero.

Most existing solutions create friction for everyone. CAPTCHAs, contribution restrictions, and strict onboarding processes often discourage the very newcomers that open-source communities want to attract.

Sats-Stamp was inspired by a different idea: instead of trying to identify spam through content analysis, change the economics of contribution. By requiring unknown contributors to post a small, refundable Bitcoin bond before their pull request enters the review queue, mass spam becomes expensive while genuine contributors pay nothing in the end.

The concept is simple: if a contribution is made in good faith and gets reviewed, merged, or triaged, the contributor receives their bond back. If it is clearly spam, the bond is forfeited. Even a tiny refundable stake fundamentally changes the incentive structure that spam relies on.

What We Built

Sats-Stamp is a GitHub App that acts as a trust-aware contribution gateway for open-source repositories.

When a pull request is opened, the application evaluates the author's trust level using GitHub-native signals such as:

• Author association with the repository
• GitHub account age
• Previous merged contributions

Trusted contributors are automatically exempted and can continue contributing without interruption.

For low-trust contributors, the bot generates a small Lightning Network bond request through LNbits and posts instructions directly on the pull request. Once the bond is paid, the pull request is marked as ready for review.

Maintainers can then decide the outcome using simple labels:

• sats-stamp:resolve → refund the contributor's bond
• sats-stamp:spam → forfeit the bond and close the pull request

To make the system flexible, we implemented a provider abstraction layer called BondProvider, allowing different payment mechanisms to be plugged into the same workflow. The MVP uses LNbits and the Lightning Network, while future implementations can support Cashu ecash and other Bitcoin-native payment systems.

How We Built It

The project was built using:

• TypeScript and Node.js
• Probot for GitHub App development
• SQLite for persistent bond state management
• LNbits as the Lightning backend
• Polar Regtest for a fully local Bitcoin Lightning test environment

The architecture is event-driven. GitHub webhooks trigger trust evaluation and bond creation workflows, while a background polling service monitors Lightning invoice payment status.

A SQLite-backed state machine tracks each contribution through its lifecycle:

This ensures the system remains reliable even if the application restarts, and prevents duplicate refunds or repeated processing of the same pull request.

Importantly, the entire project runs on free and open-source infrastructure using Bitcoin test networks, allowing us to demonstrate real payment flows without requiring any real funds.

Challenges We Faced

One of the biggest challenges was designing a refund mechanism that works reliably within the constraints of the Lightning Network.

Initially, we explored escrow-like approaches using hold invoices, but Lightning's timeout mechanics make long-lived review periods difficult to support. We ultimately adopted a custodial bond model where the bot temporarily holds the funds and issues a separate refund upon successful review.

Another challenge was maintaining a balance between spam prevention and contributor friendliness. We wanted to avoid creating unnecessary barriers for trusted contributors, which led us to develop a GitHub-native trust evaluation system that exempts established users automatically.

Working with Lightning infrastructure on test networks also introduced unique challenges. Many Lightning Address providers operate exclusively on mainnet, requiring us to design an alternative refund flow based on contributor-supplied Bolt11 invoices for test environments.

Finally, ensuring that webhook events, payment polling, database state, and maintainer actions remained synchronized required careful state management and idempotent event handling.

What We Learned

Through building Sats-Stamp, we learned that spam prevention is fundamentally an economic problem rather than a content-classification problem.

We gained hands-on experience building GitHub Apps, integrating Lightning Network payments through LNbits, managing event-driven workflows, and designing robust state machines that coordinate actions across multiple external systems.

We also discovered how Bitcoin can be used for more than payments. By introducing a tiny refundable stake, Bitcoin becomes a mechanism for establishing trust, aligning incentives, and protecting open-source communities without excluding genuine contributors.

Future Work

Beyond the MVP, we plan to expand Sats-Stamp with:

• Support for GitHub Issues in addition to Pull Requests
• Cashu ecash bond support
• Nostr-based web-of-trust exemptions
• A community-funded welcome pool for first-time contributors
• Automated expiration of unpaid bond requests

Our long-term vision is to give maintainers a lightweight, Bitcoin-powered tool that preserves openness while making spam economically irrational.

In short, Sats-Stamp doesn't try to identify spam—it makes spam unprofitable.

Built With

• bitcoin
• lnbits
• lnd
• polar