Instead of donating directly to a campaign, users commit funds under a publicly defined condition. Funds are intended to be collected up front and released only if the condition is met. (If the condition is not met, funds are not refunded and instead support the platform.)
Conditions must be externally verifiable and rule-based.
The current v1 focuses on a single condition: whether H.J.Res.54 (a proposed constitutional amendment from Congresswoman Jayapal to overturn Citizens United) receives a floor vote in the House.
This demo does not collect funds, create accounts, or process payments. It is an interactive walkthrough of the mechanics and UI flow.
The intended full version includes authentication, payment via Stripe, and automated condition resolution.
Technical stack: MERN (MongoDB, Express, React, Node), VPS deployment with Nginx reverse proxy, JWT auth in the full build, and background watchers for legislative updates.
The hard problems have been structural rather than technical: defining objective conditions, avoiding discretionary fund control, ensuring neutrality, and designing something that does not resemble a quid pro quo.
I’m interested in feedback on the escrow model, incentive alignment, legal edge cases, and whether the mechanism is clear.
Demo: https://demo.powerback.us
Happy to answer questions.
powerback•53m ago
This is an experiment in conditional escrow logic applied to campaign finance.
Donations are held and only released if a predefined, externally verifiable event occurs (e.g., a recorded House vote).
I was curious whether aligning financial incentives with observable outcomes could create a different signaling dynamic.
From a technical perspective I’d love feedback on: – escrow implementation risks – attack surfaces – legal/compliance edge cases – incentive design flaws
(It’s early and intentionally simple.)