Allowances and Payments from Your Master

What approving the payments wallet means, who can spend the allowance, and how to bound and revoke it.

A payments Pakt lets your agent pay from a wallet you already hold funds in, your master, without moving those funds into Pakt. The agent never holds the master's key. Instead the master grants your account's payments wallet an ERC-20 allowance, and each payment is a transferFrom(master, payee, amount) that the payments wallet sends only after Pakt proves it against your rules.

Payments Pakts cover USDC on Base, Arbitrum and Ethereum, USDT0 on Arbitrum and USDT on Ethereum. A payments Pakt can be active next to your Hyperliquid and services Pakts. It cannot be active while a Gateway Pakt is: both sign through one approver whose freshness check Gateway's older, finalized-block evidence would keep failing. Disable the Gateway Pakt first.

What `approve(payments wallet, amount)` means

An allowance is the amount a token contract lets one address (the spender) move out of another (the owner) with transferFrom. Setting up a payments Pakt, each chain's master sends, once per token:

approve(payments wallet, amount)

to the token contract. Two parties can spend that allowance:

Pakt, through this Pakt: it signs the payments wallet's transaction only when the proof admits it (a listed payee, within each token's and payee's ceiling) and refuses everything else.
The payments wallet's owner login. The payments wallet is a second Privy wallet you own, created in the dashboard. Pakt's restricted signer is attached to it as an extra signer, but your own Privy login (or a key you export) can still sign any transaction from it, including transferFrom up to the whole allowance, without this Pakt.

So the allowance, not the Pakt, is the most that can leave the master. Approve a bounded amount you accept being spent and raise it when needed. The dashboard suggests ten times the token's largest single payment in this Pakt. Pakt refuses a payment above the remaining allowance before proving anything. See Signers, Wallets, and Control.

What the Pakt allows

A payments Pakt commits three rules, and optionally budgets, all checked inside the proof:

Rule	What it fixes
`payments-wallet`	The payments wallet that sends every transfer, and for each chain the one master it spends from, the gas limit and the highest fee per gas it pays
`payment-assets`	The tokens, each on its own chain, and each token's largest single payment
`payment-payees`	The payees, each on its own chain, with an optional date window, its own largest payment and up to four tags. Payments payees are listed only: the unlisted ceiling is 0 and no entry has a service pattern
`payment-budgets`, `payee-recurrence` (optional)	How much may leave the master per trailing or UTC calendar window, for all payees, a tag or one payee, and how much one payee may receive per period

A payment must name a token and chain from payment-assets, a chain with a bound master, and a payee listed for that chain. It is refused above the token's or the payee's ceiling, when the master's balance or allowance is too low, or when the network fee is above the Pakt's ceiling. A payee listed only on Base is refused on Arbitrum. See Rules and Limits for how these rules apply.

Without budgets, each payment is checked on its own: an agent can make many payments up to the ceilings until you disable the Pakt or revoke the allowance. A budget counts everything that leaves the master in the budget's tokens, to any destination, including transfers you make from the master yourself, so your own spending uses up the same budget. See Budgets and Payee Limits.

Refills and returns

Refill. By default the payments wallet itself is listed as the refill payee, tagged refill, on every chain the Pakt binds, up to the largest token ceiling on that chain; the dashboard review marks it. A budget scoped to the tag refill caps refills. A refill moves funds from the master into the payments wallet, which pays for services (x402 and MPP) from its own balance.
Return. Sending the payments wallet's balance of a listed token back to the chain's master is always allowed. It needs no payee entry and has no ceiling beyond the payments wallet's balance.

Setting up the allowance

Open the active payments Pakt in the dashboard. Allowances from your master lists each token and chain with:

Approve a bounded amount from a wallet connected in the browser. Enter the allowance in token units; the field starts at ten times the token's largest payment in this Pakt. The connected account must be that chain's master; the dashboard switches the wallet to the token's chain and sends approve(payments wallet, amount).
Copy calldata for the entered amount, for a Safe (paste it into Safe Transaction Builder), a hardware wallet, or a custodian. Send it from the chain's master to the token contract with value 0. The selector is 0x095ea7b3.
The current allowance, read through the connected wallet's network. It is informational and never affects what Pakt authorizes; Pakt reads the allowance it checks itself.

USDT on Ethereum

USDT on Ethereum (0xdAC17F958D2ee523a2206206994597C13D831ec7) refuses to change a non-zero allowance to another non-zero value. When its current allowance is not 0, first send approve(payments wallet, 0), wait for it to be mined, then send the new approval. The dashboard does this for a connected wallet, and lists the reset step first under Copy calldata. Sending the reset when the allowance is already 0 is harmless.

Gas

The payments wallet sends every transfer, so it pays the network fee in ETH. Keep ETH in the payments wallet on each chain the Pakt binds. The master pays only the gas for its own approve transactions.

Revoking

To stop all payments from a master at once, send from that master:

approve(payments wallet, 0)

to each token contract, with Revoke in the dashboard or the copied calldata. Pakt then refuses every payment from that master before proving. Disabling the Pakt also stops new payments, while the allowance stays in place for a later Pakt. A transfer Pakt already signed can still be mined; revoking or disabling does not recall a signed transaction.