Lift policies and keys
A Lift policy authorizes sponsorship for one integration. The integration's key identifies the project and workspace; the policy decides which operations that key may sponsor.
Access and key lifecycle
Workspace members can view Lift. Owners and admins can create integrations, rotate or revoke keys, and create, update, enable, or pause customer policies.
Secret keys start with lift_sk_. A newly created or rotated key is shown once. Lift stores its hash and displays only identifying metadata afterward; keep the original in your server's secret manager.
Rotation replaces the integration's key immediately. Update your application's secret configuration as part of the rotation. Revoking an integration stops new authorization and prevents rotating its key or adding policies to it. Create a new integration if you need to resume with a replacement.
Use the Bearer header on server-side requests. Requests containing an Origin header are rejected. The API does not support query-string authentication or browser CORS for secret keys.
Policy fields
| Field | Meaning and validation |
|---|---|
| Name | 1–80 characters after trimming |
| Chains | 1–20 distinct positive chain IDs; runtime availability is checked separately |
| Allowed senders | 1–100 nonzero account addresses |
| Allowed factories | Up to 100 nonzero addresses; factory operations are currently rejected regardless of this list |
| Permitted contracts | 1–100 unique nonzero target addresses |
| Selectors per contract | 1–100 four-byte hex selectors, such as 0xa9059cbb |
| Per-operation maximum | Positive amount, at most $1,000,000 |
| Daily budget | Positive amount, at most $1,000,000 and at least the per-operation maximum |
| Enabled | Must be enabled to issue sponsorship |
Amounts are stored in whole microUSD: $1 is 1_000_000 microUSD. The console accepts dollar amounts. Daily accounting uses UTC days.
In the console's permitted-calls field, enter one contract per line followed by its selectors:
0x1111111111111111111111111111111111111111 0xa9059cbb
0x2222222222222222222222222222222222222222 0x095ea7b3 0x23b872ddThese addresses are placeholders. Replace them with contracts you intend to sponsor. For example, 0xa9059cbb is the selector for transfer(address,uint256); allowing it permits that function, without restricting its recipient or amount at the Lift policy layer.
What the allowlist checks
Lift checks the chain, sender, outer destination contract, and four-byte selector. Empty sender and target lists are rejected; they never mean unrestricted access.
The current adapter additionally rejects native-value transfers, calls to the sending Safe itself, protected account infrastructure, setup calls, batching, and delegatecall. An allowlisted selector cannot override these adapter restrictions.
Lift does not express function-argument restrictions in a customer policy. If a call requires recipient, amount, or other argument restrictions, enforce those in the application's authorization and on-chain account or contract permissions. Sponsorship does not replace the account's signature requirements.
Budgets and capacity
Lift checks policy budgets and pending operations alongside shared chain capacity and sponsorship funding. A policy may have at most 100 pending operations. Creating a customer integration checks a workspace limit of 200 integration records; policies have a workspace limit of 500 records. Revoking or pausing a record does not delete it.
The Sepolia pilot quotes and settles at zero microUSD. Dollar budgets therefore do not bound the pilot's native gas consumption; chain gas budgets, daily operation limits, per-operation gas/fee limits, and pending-operation limits still apply. Their values depend on the enabled deployment.
Changes affect future authorization
Saving a policy increments its version. Lift rechecks key and policy versions before returning authorization and again before accepting a submission. Pausing a policy or revoking a key stops new authorization and can make an in-flight submission fail through Lift.
An already-issued on-chain paymaster signature may remain usable until it expires. Policy changes do not revoke that signature on-chain or instantly free its reservation. See settlement and release.
Managed policies
Policies marked as managed belong to Flow. They issue no customer secret key and are maintained from the associated Roles profile. Change that profile's scope through Flow; direct editing of managed Lift policies is refused. Read Lift with Flow for the full lifecycle.