Constant. | Devpost

Recipients
Dashboard
History
Landing Page
Send
backtest
Shield

Inspiration

Remittances are supposed to be reliable family support, but in high-inflation countries the value can leak away after the money arrives. Hundreds of billions of dollars move across borders every year, and a lot of that money lands in currencies that can lose value before families actually spend it. The painful part is that the transfer itself may be fast, but the money still gets converted all at once, then sits exposed until rent, school fees, groceries, or medical bills are due.

That felt like the wrong default. Families do not spend a monthly transfer all on day one, so the conversion should not have to happen all on day one either. We built Constant around that idea: keep the crypto complexity invisible, hold value in something stable, and convert only when the recipient actually needs local currency.

What it does

Constant is a remittance wallet that protects transfers from inflation by timing conversion, not just moving money faster. A sender deposits stablecoins through Unifold, sends money to a recipient's Constant $tag, and the recipient's currency profile decides what happens next.

For supported corridors like Argentina, Nigeria, and Turkey, a deterministic Python engine splits the transfer into tranches. Some converts immediately for essentials, some is held in stablecoin, and the rest drips out over time, always within a six-week maximum. The split is based on corridor depreciation, volatility, and the recipient's upcoming tagged spend.

The safety rules are hard-coded: funds are never fully withheld, essentials come first, and every cent converts by the deadline. Every decision is logged with the raw inputs and a plain-language explanation, like why 40 percent is being held or why rent due soon forces more immediate conversion. The dashboard then shows the number we care about most: how much value was preserved compared with converting everything on arrival.

How we built it

The frontend is built with Next.js, TypeScript, Tailwind, and shadcn/ui. It covers signup, wallet funding, the send flow, recipient lookup by $tag, transfer history, tranche timelines, and the savings dashboard.

The backend is FastAPI, SQLAlchemy, Postgres on Supabase, and JWT auth. It owns users, balances, deposits, withdrawals, recipients, transfers, tranches, FX rates, wallet transactions, and decision logs. Wallet balance changes and transfer records happen inside the same database flow so the money movement and the explanation stay tied together.

The strategy engine is a pure Python module with no network calls, no randomness, and no LLM in the decision path. Given the same amount, rates, spend schedule, and date, it always returns the same tranche schedule. The LLM is only used after the fact to explain a decision that already happened, with deterministic fallback copy if generation fails.

Unifold handles stablecoin deposits and Polygon USDC payouts through a treasury wallet, with signed webhooks and reconciliation for settled deposits. We also built an autopilot sweep that checks active transfers for due tranches, rate spikes, or regime changes and replans when needed.

For evidence, we ran the same deterministic strategy against historical CAD to ARS, NGN, and TRY rate data. The committed backtest replayed 81 transfers, preserved $43.34 CAD versus convert-on-arrival, had 0 essentials shortfalls, and reduced arrival-day FX exposure by 13.5% on average.

Challenges we ran into

The hardest part was keeping the product honest. It is easy to pitch "AI that protects remittances," but it is much harder to build something you could actually explain to a family. We had to draw a hard line: the engine decides, the LLM explains. That took longer, but it made the system testable, auditable, and much safer.

Currency behavior was also messier than the original pitch. Real corridors do not move smoothly, public rate data has gaps, and official rates can diverge from what people actually experience locally. We chose to report the limitations instead of hiding them: our backtest uses real historical rates, but execution is still simulated and does not yet model spreads, fees, or settlement latency.

The Unifold integration also had real product details behind it: deposit state handling, webhook settlement, idempotency, reconciliation, and payout status. Making crypto feel invisible meant doing a lot of plumbing that users should never have to think about.

Accomplishments that we're proud of

We shipped more than a demo wallet. We built a deterministic remittance strategy with enforced safety constraints, real decision logs, receiver-owned conversion schedules, and a backtest that puts a number on the value preserved.

We are especially proud that the safety constraints actually bind. In the backtest, Constant had zero essentials shortfalls, while a naive "hold everything until week six" strategy created 72 shortfall events. Removing the essentials floor created 25. That gave us proof that the boring guardrails were not just nice-to-have risk language; they were the core product.

We also kept the crypto mostly invisible. A sender does not need to understand chains, bridges, stablecoins, treasury wallets, or FX regimes. They just fund their wallet, send to a $tag, and see a clear timeline of what will convert, when, and why.

What we learned

We came in thinking the main problem with remittances was speed and throughput. We left thinking the bigger bottleneck is trust. Families do not just need money to arrive; they need to understand what is happening to it after it arrives.

Stablecoins became more practical to us during the build. Not as a speculative asset, but as a way for someone without a U.S. bank account to hold value in a more stable unit until they need local currency. The crypto story was strongest when we removed most of the crypto from the user experience.

We also learned that explainability changes the whole feel of the product. Once each conversion had a readable reason, the strategy stopped feeling like a black box and started feeling like something you could actually hand to a parent.

What's next for Constant

Next, we want to tune more corridors individually. Argentina, Nigeria, and Turkey do not behave the same way, and a serious version of Constant should not force them into one global strategy.

We also want recipient-side controls so families can edit their own spend tags, request early releases, and choose how conservative the schedule should be within the safety limits. Local cash-out partnerships and mobile money integrations would make the last mile feel as simple as the first.

The strongest future version is point-of-sale autoconversion: let recipients keep value in stablecoin until the exact moment they spend, then convert automatically. That removes most of the need for scheduled conversion at all.

Beyond product features, the big next steps are regulatory: custody, licensing, compliance, KYC, asset eligibility, and a longer evidence base across more corridors and real currency crises. We also want to open source the strategy engine, because if families are trusting a schedule with their money, the code producing that schedule should be inspectable.