Skip to content
Thyme Docs

Lift with Flow

Flow's supported Safe Roles profiles use a managed Lift integration to sponsor execution. Flow creates and maintains this integration as part of profile setup. You do not create a public Lift key, call the paymaster from task code, or put a Lift secret in task secrets.

Managed integration and profile policy

An active managed integration belongs to the Flow project. Each Roles profile has a policy that authorizes:

  • The profile's executor Safe as the sender.
  • The profile's chain.
  • The customer's Roles proxy as the destination.
  • The Roles execution selector as the permitted outer call.

The executor account is distinct from the customer Safe that holds assets. Flow validates every inner call the task returns against the profile scope, while the on-chain Roles permissions enforce what the executor may do. Lift authorizes sponsorship for the outer call through that Roles proxy.

A run that returns several calls is sponsored as one operation: the executor Safe delegatecalls the pinned Safe MultiSendCallOnly contract, and each entry is a separate zero-value execTransactionWithRole into the Roles proxy. Managed integrations are the only Lift callers allowed that shape; every entry must still pass the same target and selector allowlist as a single call, and Lift verifies the MultiSendCallOnly bytecode before sponsoring it. The batch is atomic — if any entry fails, the whole operation reverts.

The runtime still applies Lift's current Sepolia-only, deployed-Safe4337 restrictions. A Flow profile kind or chain being listed elsewhere does not extend Lift's available chains.

Setup and execution are separate

Roles onboarding can have its own Flow setup and relay flow. The public Lift paymaster API still rejects account deployment and setup UserOperations. A managed profile must have the supported executor account deployed before its execution can be sponsored through Lift.

For profile creation, ownership, scope approval, and revocation, start with Flow profiles.

Changing or revoking a profile

Flow updates its managed policy when the Roles profile scope changes, incrementing the policy version. Revoking a role or deleting the profile also disables its sponsorship policy. Managed policies are read-only through Lift's customer policy management actions, and managed integrations issue no API key.

Changes stop new authorization. Already-issued sponsorship can remain executable until expiry, so an operation's reservation may outlive a policy change. The same reconciliation rules apply to managed and public integrations.

Execution records and billing

Flow links each sponsored execution to its Lift operation before submission. This lets you correlate task runs, profile activity, UserOperation hashes, and gas outcomes.

Lift settles the gas for the linked operation. Flow does not separately debit that same gas through its ordinary execution billing path. Flow compute usage and other service usage remain separate from sponsored gas. The current Sepolia pilot settles sponsored gas at zero dBank.

Troubleshooting a sponsored task

If a task runs but its transaction cannot be sponsored:

  1. Check that the Roles profile is active and its setup is confirmed.
  2. Verify that the task's target and selector are within the approved profile scope.
  3. Check the execution's error and its linked Lift operation.
  4. Check the enabled Sepolia pilot and whether a chain or pending-operation limit was reached.
  5. Wait for a pending authorization to reconcile before assuming it can be discarded.

An otherwise valid task can be refused while gas prices exceed deployment limits or shared sponsorship capacity is exhausted. Use the returned error to distinguish capacity from a scope or account-configuration failure.