Lift operations and billing

Lift creates an operation record when it reserves capacity for sponsorship. Creating a key or policy alone does not send a transaction or create a sponsored operation.

Operation states

UserOperation success is separate from the containing transaction's success. A bundler transaction may succeed while an individual UserOperation reverts. Reverted operations can consume gas.

Follow an operation

The Operations page lists integration, creation time, status, chain, sender, reserved amount, actual charge, and the transaction explorer link when available. It loads 25 operations at a time, with Load more operations for history.

Save the Lift operation ID and UserOperation hash in your application's own request log. The final paymaster response includes operationId; the submission response is the UserOperation hash. The eventual transaction hash identifies the chain transaction containing the operation.

Receipt reads through Lift also prompt a targeted reconciliation pass when a receipt is present. Reconciliation runs independently of the submitting bundler, so a slow response does not automatically mean an operation was lost.

Reservations and settlement

Before signing, Lift reserves policy and shared chain capacity and checks sponsorship funding against outstanding exposure. It settles from verified on-chain receipt data once the deployment's configured confirmation threshold is met.

Settlement initially has provisional finality. When the block becomes finalized, Lift audits the result. If a reorganization changes inclusion, the reconciliation process can adjust the gas charge or refund an operation that is not included again. Pending capacity is freed at settlement; the later finality audit protects accounting accuracy.

Expiration alone does not release a signed authorization. Lift must establish non-inclusion using finalized chain data beyond its validity window. A client timeout, RPC failure, or missing bundler receipt is insufficient proof.

Sepolia billing

The current pilot charges zero dBank for Sepolia gas while recording native gas use. The operation may therefore show zero reserved dollars and zero actual charge even though it consumed testnet gas and occupied capacity.

Policy dollar budgets, workspace dBank balances, and operation reservations use microUSD accounting. Mainnet sponsorship remains unavailable in the current Lift adapter. Do not treat a saved mainnet policy as evidence that mainnet gas can be sponsored.

Where a balance is shown, it belongs to the entire workspace, including its other projects. Available balance is the balance minus outstanding monetary reservations.

Usage totals

Lift's overview and usage summaries cover operations created in the last 24 hours. They are not a full historical invoice or a report of every operation settled in that period. The summary processes up to 1,000 recent operations and reports when that view is truncated; use operation history to inspect individual records.

Retrying and recovery

Never send your Lift secret or account signing key with a support request. A reservation may deliberately remain held when receipt recovery cannot prove a safe outcome.