Security model

What protects a payment from being redirected, and what you still have to trust.

Tazor is built so that a payment can't be redirected: not by a stolen phone, a former employee, a hacked server or a tampered website. This page lists what enforces that, and what you still trust.

What you sign is what you see

Your device rebuilds the payment from the invoice link and compares its digest with the payment contract's before asking for your passkey. If they differ, it refuses to sign.

Checks on every payment

Each approver's signature is checked by their approver account on-chain.
Each approver must be a WhiteBIT-verified person (WB Soul), and two approvers must be different people.
No approver may be on the company's revocation list.
Each approver must hold the approver role on the company's ENS name, from the role cache.
On v2 accounts: limits, the new-payee delay and the fresh-proof rule from Policies.

No back door over funds

The company account only lets Tazor's installed payment modules move funds, and only after these checks. There is no owner key and no upgrade key over company funds.

Keys

Approver keys are passkeys in the platform keychain, synced across the user's own devices and never sent to Tazor. Signatures are verified with Whitechain's P-256 precompile.

What you still trust

WhiteBIT decides who is a verified person. It can revoke a person's verification; it cannot move company funds.
Whitechain's proposer is permissioned. We only claim that payments get in, not that withdrawals to Ethereum get out.
Tether can freeze USDT held by any address.
Whoever controls the taz0r.eth contenthash could serve a different app. The digest check above limits the damage, and the app build is reproducible, so anyone can compare it with the published version.