Menu
Home Shop Owner Architecture Brief
Sections
01 / Key Management 02 / Checkout Fees 03 / Gas Fees 04 / Checkout Flows
Partner Technical Brief

Non-Custodial
by Design

BitVoy never holds user funds — across key management, payment fees, and gas fees. This document explains how.

Dimension ❌ Custodial Pattern ✅ BitVoy's Design
Key Management Server holds private key FROST MPC 2-of-3; server alone cannot sign
Checkout Fees BitVoy receives full amount, deducts fee, forwards to merchant AA: atomic split inside SA · STANDARD: atomic split via PaymentRouter (Permit2)
Gas Fees Gas deducted from user's tokens AA: Paymaster sponsors gas · STANDARD: user pays in native token
01 / Key Management

FROST MPC — 2-of-3 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.

🌐

Party 3 — Guardian Node

Distributed nodes hold the third share, encrypted with AES-256-GCM. Used for account recovery.

🔒 Non-Custodial Rationale: Signing requires 2-of-3 shares. The server's share alone is cryptographically useless. 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.

AA 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)
STANDARD Mode PaymentRouter + Permit2

BitVoyPaymentRouter.sol pulls tokens via Permit2 and splits within the same atomic transaction.

// Within a single transaction Permit2.permitTransferFrom(User → Router) ↓ Same tx safeTransfer(merchant, amount - fee) safeTransfer(feeRecipient, fee) // No tokens ever remain in PaymentRouter
Tamper-proof via Permit2 signature (amount, deadline, nonce)
Revert on fail Funds remain with user if tx fails
Gas Paid by user in native token
❌ Custodial Pattern ✅ BitVoy's Design
Fund Flow User → BitVoy → Merchant Contract splits directly (AA: inside SA, STANDARD: via Router)
Intermediate Custody Yes — BitVoy temporarily holds funds None — instant distribution within the same tx
Tampering Risk BitVoy could manipulate amounts AA: intentHash signature · STANDARD: Permit2 signature prevents tampering
03 / Gas Fees

Verifying Paymaster Sponsorship

BitVoy sponsors gas costs — without touching the user's ERC-20 tokens.

How It Works

Step 1
BitVoy deposits native tokens (ETH / AVAX / POL) into BitVoyPaymaster.sol
Step 2
When a UserOp is submitted, the server signs an OP signature in paymasterAndData, authorizing gas sponsorship for this specific UserOp
Step 3
The EntryPoint settles gas costs from the Paymaster's deposit to the Bundler — user's ERC-20 balance is never touched

paymasterAndData 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.
04 / Checkout Flows

OIDC Payment — Step-by-Step

Detailed flow for both modes showing exactly where signatures and splits occur.

AA Mode 1 MPC signature
1
Server retrieves intent → computeIntentHashV3
2
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
STANDARD Mode 2 MPC signatures
1
Client → Server: POST /prepare — server generates Permit2 EIP-712 typed data
2
Client signs Permit2 EIP-712 hash via MPC (Signature 1)
3
Client → Server: POST /execute — server builds payWithFee() callData
4
Client signs transaction via BitVoyMPCBridge & broadcasts (Signature 2)
5
On-chain: PaymentRouter.payWithFee() → Permit2 pull → atomic split to merchant + fee recipient
Feature Mode Fee Method Contract Mechanism
OIDC Payment AA executeIntentV3 BitVoySmartAccountIBUOv3 On-chain split inside SA
OIDC Payment STANDARD payWithFee BitVoyPaymentRouter Permit2 Pull → Split transfer
Conclusion

Non-Custodial Across All Three Layers

BitVoy employs a non-custodial design across key management, payment fees, and gas fees. BitVoy does not hold or manage user funds at any point. This is the essence of non-custodial design.