The Paymaster Pattern
A paymaster is a Clarity contract that atomically collects a SIP-010 fee from the user and executes a protocol action in a single transaction.When Do You Need a Paymaster?
For DEVELOPER_SPONSORS, you build any contract call as a sponsored transaction and call
velumx.sponsor(). No paymaster contract involved.
For USER_PAYS, you need a paymaster because the SIP-010 fee transfer must happen atomically with the protocol action. If the action fails, the fee reverts. This guarantee requires an on-chain contract.
The Pattern
Every paymaster function follows the same three-step pattern:The VelumX DeFi Reference Paymaster
VelumX deploysvelumx-defi-paymaster-v1-1 for the VelumX DeFi frontend. It supports:
- Bitflow StableSwap pool swaps (all pools, both directions)
- Bitflow multi-hop router swaps (all router contracts)
- Velar XYK and stableswap router swaps (single-hop through 4-hop)
- USDCx bridge (burn for cross-chain withdrawal to Ethereum)
Building Your Own Paymaster
- Copy
velumx-defi-paymaster-v1-1.clarfrom the VelumX Contracts repo - Replace the Bitflow/USDCx calls with your own protocol calls
- Keep the
collect-feeprivate function exactly as-is - Deploy to mainnet
- Point your SDK calls at your paymaster contract address
The collect-fee Function
This is the only piece of the paymaster that must stay unchanged. It handles the atomic fee transfer and enforces the two security invariants:
ERR-ZERO-FEE— prevents zero-fee calls that would let users bypass the fee entirely.ERR-SELF-TRANSFER— prevents the user from setting themselves as the relayer to collect their own fee.
Minimal Paymaster Example
Replacedo-thing with your own protocol call. The fee args (fee-amount, relayer, fee-token) are always the last three parameters by convention.
Calling Your Paymaster from the SDK
The relayer address always comes fromestimateFee() — never hardcode it. The relayer address can change when VelumX rotates keys or reassigns your project to a different node.
What the Paymaster Does NOT Do
- No on-chain token whitelist — the relayer validates supported tokens off-chain
- No fee cap enforcement — the relayer enforces caps per API key
- No admin key or upgrade mechanism — the contract is immutable once deployed
- No VelumX-specific registry or trait required