Our story
We started JuicePay because moving money between chains was reliable in theory and miserable in practice.
The problem we kept running into
Between us we had built payment systems at exchanges, a treasury desk, and two companies that paid contractors in six countries. Every one of those systems eventually broke on the same thing: value arriving on a chain nobody had planned for, and a finance team reconciling it by hand.
The tooling existed to move money onchain. What did not exist was tooling to move money onchain and still know, at the end of the month, exactly what happened and why.
What we decided to build
We chose settlement as the problem to solve properly: one balance per asset regardless of chain, one ledger for every movement, and status you can book without a caveat.
That led to three commitments that have not changed since the first commit.
- Finality over speed as the default — announce success when it is actually safe to.
- Transparency over convenience — show the venue, the impact, and every fee as its own line.
- Idempotency as a system property — retries should be safe by construction, not by discipline.
How we work
We are a small, engineering-heavy team distributed across three time zones. Incidents are written up publicly in the changelog. Design decisions are argued out in documents that outlive the argument.
We do not have a sales team that gates the product. Sandbox access is free and instant, because the fastest way to evaluate a settlement provider is to send it money that does not matter.