Security that does not depend on trusting us.

What "non-custodial" means here

Our servers watch the chains read-only and match payments to invoices. They cannot sign a transaction that moves your funds, so a breach would expose no key that spends your money. We cannot freeze, delay or lose what we never hold. As with any wallet, a token's issuer can still freeze that token on chain.

Every address is checked on the payer's device

A breached server could try to show payers an address that is not yours. So you give the checkout your list of addresses ("pins"), carried in the URL fragment, which browsers never send to a server. The checkout checks each deposit address against them on the payer's own device, and shows nothing if the check fails. Without pins, it refuses addresses from your own wallets outright.

Matched by address, never by a claim

Tillsafe never credits a payment because someone pastes a transaction ID.

• Each deposit address belongs to one invoice at a time: its 24-hour window, then a 72-hour cooldown.
• Each transfer is recorded once, keyed by chain, transaction and position.
• A transfer nobody can attribute goes to a person to resolve. It is never guessed at.

Credited only when final

A payment counts once its chain says it cannot be undone: solidified blocks on TRON, finalized blocks on BNB Smart Chain, 1 to 6 confirmations on Bitcoin by size. If a chain reorganizes, the credit is reversed and you are told. A payment of US$250,000 or more waits for someone on your team to accept it.

Important changes are slow on purpose

Changing your payout address, webhook URL or webhook secret happens only on the dashboard, needs an owner or admin with a passkey check from the last 5 minutes, and takes effect after 24 hours by default. Every owner and admin is emailed and can cancel it. A leaked live API key cannot redirect your money or your webhooks.

Account and webhooks

• Passkey sign-in, and owner, admin, developer, finance and viewer roles.
• An audit log the application cannot edit or delete.
• Secret API keys stored only as keyed hashes; webhook secrets and payer emails encrypted at rest.
• Webhooks signed with HMAC-SHA256 over a timestamp and the body, sent only to public HTTPS endpoints, retried for about 72 hours.

Refunds go where the payer says

The payer picks the refund address through a private link. It is checked against the US sanctions list and the token issuer's blacklist, and held if it matches.

How we test

• Money is exact integers, never floating point, in a double-entry ledger whose database rejects any entry that does not balance.
• Property-based tests for money and payment state; browser tests of the checkout in every language and theme.
• Two internal security reviews, with every high-severity finding fixed.

Where we are

Tillsafe is in early access. We would rather you hear the gaps from us.

• No independent audit or penetration test yet. We plan both before general availability.
• Incoming-payment screening is coming. Today refund addresses are screened. Next, every sender is checked against sanctions lists and issuer blacklists before a payment is credited.
• Forwarding contracts are coming. Deposit addresses that are contracts able to pay only your wallet, with no owner and no upgrade path. They pass 107 tests, including fuzzing and invariant tests, with 100% line and branch coverage. They are not yet audited or deployed; until they are audited, deposits go to wallets you own.

Report a vulnerability

Report it through the early-access form, starting your message with "Security report". Give us reasonable time to fix an issue before sharing it, and do not access data that is not yours.