01 / Key Management
FROST MPC — 2-of-2 Threshold Signing
No complete private key exists anywhere. Signing requires cooperation from at least two parties.
Party 1 — User
Key share stored in the browser, encrypted with Passkey PRF → AES-256-GCM. The server cannot decrypt it.
Party 2 — BitVoy Server
Holds one encrypted share only. Cannot produce a valid signature alone. Server compromise ≠ fund loss.
Backup — Guardian Node
Stores an encrypted backup of the user's share (Party 1). Encrypted by the user with Passkey PRF → AES-256-GCM before upload — the Guardian cannot decrypt or use it for signing. Used solely for account recovery.
Non-Custodial Rationale: Signing requires both shares (Party 1 + Party 2). The server's share alone is cryptographically useless. The Guardian holds only an encrypted backup of the user's share and cannot participate in signing. Private key export is intentionally unsupported — the complete key is never reconstructed in a single location.
02 / Checkout Fees
On-Chain Atomic Fee Splitting
Funds are split directly on-chain in the same transaction — BitVoy never receives and redistributes.
SMART Mode
V3 Smart Account
Fee splitting via executeIntentV3 in the Smart Account contract.
// User's SA Balance
safeTransfer(merchant, amount - fee)
↑ To merchant
safeTransfer(feeRecipient, fee)
↑ To fee recipient
// Funds never pass through BitVoy's wallet
Tamper-proof via
intentHash signed by user + OP
Fee cap
MAX_FEE_BPS enforced on-chain
Gas
Sponsored by Paymaster (zero cost to user)
FAST Mode
EIP-3009 transferWithAuthorization
User signs EIP-3009 transferWithAuthorization via MPC. OP Signer submits on-chain, splitting funds atomically to merchant and fee recipient. USDT uses Permit2 + PaymentRouter as fallback.
// EIP-3009: Two authorized transfers
transferWithAuthorization(user → merchant, payeeAmount)
↑ Signed by user via MPC
transferWithAuthorization(user → feeRecipient, fee)
↑ Signed by user via MPC
// OP Signer submits both — user pays zero gas
Tamper-proof via
EIP-3009 signature (from, to, value, nonce, deadline)
Revert on fail
Funds remain with user if tx fails
Gas
Sponsored by OP Signer (zero cost to user)
| ❌ Custodial Pattern | ✅ BitVoy's Design | |
|---|---|---|
| Fund Flow | User → BitVoy → Merchant | Contract splits directly (SMART: inside SA, FAST: EIP-3009 direct transfers) |
| Intermediate Custody | Yes — BitVoy temporarily holds funds | None — instant distribution within the same tx |
| Tampering Risk | BitVoy could manipulate amounts | SMART: intentHash signature · FAST: EIP-3009 signature prevents tampering |
03 / Gas Fees
Gas Sponsorship by BitVoy
BitVoy covers gas costs in both modes — without touching the user's ERC-20 tokens.
SMART Mode
Paymaster Sponsorship
How It Works
Step 1
BitVoy deposits native tokens (AVAX / ETH) into
BitVoyPaymaster.solStep 2
When a UserOp is submitted, the server signs an OP signature in
paymasterAndData, authorizing gas sponsorship for this specific UserOpStep 3
The
EntryPoint settles gas costs from the Paymaster's deposit to the Bundler — user's ERC-20 balance is never touchedpaymasterAndData Structure — 97 bytes
paymasterAddress 20 bytes
validUntil 6 bytes (uint48)
validAfter 6 bytes (uint48)
signature 65 bytes (ECDSA r, s, v)
The Paymaster covers gas costs only — no ERC-20 transfer logic exists in the contract. Payment amount, destination, and token validation are handled exclusively by the Smart Account. Gas sponsorship is BitVoy's service cost, not custody of user funds.
FAST Mode
OP Signer Sponsorship
How It Works
Step 1
User signs an EIP-3009
transferWithAuthorization via MPC — authorizing a specific token transfer without spending gasStep 2
BitVoy's OP Signer submits the signed authorization on-chain, paying the gas fee in native tokens (KAIA / POL / AVAX / ETH)
Step 3
The token contract executes the authorized transfer — user's native token balance is never touched
The OP Signer pays gas costs only. The transfer amount, recipient, and deadline are locked by the user's EIP-3009 signature and cannot be altered. Gas sponsorship is BitVoy's service cost, not custody of user funds.
04 / Checkout Flows
OIDC Payment — Step-by-Step
Detailed flow for both modes showing exactly where signatures and splits occur.
SMART Mode
1 MPC signature
1
Server retrieves intent →
computeIntentHashV32
Server builds
executeIntentV3 callData (V3 ABI)3
Server constructs UserOperation (callData + paymasterAndData)
4
Client signs UserOp via MPC (1 signature)
5
Server appends OP signature → submits to Bundler
6
On-chain: EntryPoint → SA.validateUserOp →
executeIntentV3 → atomic split
FAST Mode
2 MPC signatures
1
Client → Server:
POST /prepare — server generates EIP-3009 TransferWithAuthorization EIP-712 typed data (payee + fee)2
Client signs payee transfer via MPC (Signature 1), then fee transfer (Signature 2)
3
Client → Server:
POST /relay — OP Signer submits both transferWithAuthorization calls on-chain4
On-chain: token contract executes authorized transfers → atomic split to merchant + fee recipient
5
USDT fallback: Permit2 +
PaymentRouter.payWithFee() (EIP-3009 not supported by USDT)| Feature | Mode | Fee Method | Contract | Mechanism |
|---|---|---|---|---|
| OIDC Payment | SMART | executeIntentV3 |
BitVoySmartAccountIBUOv3 | On-chain split inside SA |
| OIDC Payment | FAST | transferWithAuthorization |
ERC-20 Token Contract | EIP-3009 direct transfers (USDT: Permit2 fallback) |