Onchain actions

The Onchain transaction action (ONCHAIN_TX) makes a call from your Safe when a flow runs: pay an invoice when a deposit arrives, top up a wallet that runs low, pause a contract on a VIGIL alert. It is off unless you set it up, and it can only do what your Safe granted. Team plan.

How it stays limited

• Your keys stay yours. IGNITRA creates its own session key for each grant. Your Safe gives that key a role in a Zodiac Roles v2 modifier: specific contracts, specific functions, and nothing else.
• Limits on chain. ETH per call and per day, token amounts per call and per day, and the expiry are enforced by the Roles modifier and IGNITRA's stateless IgnitraSessionBounds check, not only by IGNITRA. Even a compromised server could do no more than the grant.
• Never the Safe itself. A grant can not target the Safe, its Roles modifier or any other enabled module, and never delegatecalls. Functions that move tokens (transfer, approve, transferFrom, increaseAllowance) must cap their amount. Expiry is between 10 minutes and 90 days.
• Off by default. A flow must opt in (settings.onchain: true) and run on confirmed events.
• Revocable at once. Revoking in IGNITRA deletes the session key immediately: nothing more is signed or sent, not even a transaction that was signed and not sent yet. Removing the role from the Safe as well is one more transaction, prepared for you.
• Logged. Every attempt is recorded with the call, the MANDATE decision and the transaction hash, on the grant's page and in the run trace.

Set it up

1. In Onchain, create a grant: your Safe, the contracts and functions, the limits, the expiry, and optionally a MANDATE policy.
2. Approve it on the Safe. It is one Safe transaction listing every call: deploying the Roles modifier and the bounds contract the first time, enabling the modifier, giving the role, scoping each function, setting the daily limits. If you own a 1-of-N Safe, send it from your wallet; otherwise import the Transaction Builder file in the Safe app and collect the signatures.
3. IGNITRA verifies the mined transaction: it replays every Roles event and checks the resulting permissions are exactly the grant, nothing broader. Only then is the grant active.
4. Send a little ETH to the grant's session key: it pays the gas of its own transactions.
5. In a flow, add an Onchain transaction step, pick the grant, the contract and the function, and turn on Onchain transactions in the flow's settings.

{
  "step_id": "pay",
  "type": "ONCHAIN_TX",
  "params": {
    "grant_id": "grt_…",
    "to": "0x5fc5360d0400a0fd4f2af552add042d716f1d168",
    "function": "transfer(address to, uint256 amount)",
    "args": ["{{trigger.from}}", "1000000"],
    "value": "0"
  }
}
// and in the flow's settings: { "mode": "confirmed", "onchain": true }

What happens when it runs

1. The call is checked against the grant: contract, function, ETH and amounts, today's totals.
2. MANDATE is asked, when the grant names a policy: only an explicit allow continues.
3. The call is simulated as the session key: a refusal by the Roles modifier is explained (e.g. the daily limit is used up) and nothing is sent.
4. The transaction is signed and recorded, then sent, and its receipt awaited.

• Exactly once. A step is signed at most once. A retry re-sends the same signed transaction, never a second one, and a step that already has an outcome answers with it.
• TEST runs only simulate: the trace shows simulated: true and the estimated gas, and nothing is signed.
• The step's output is tx_hash, block_number, gas_used, explorer_url, simulated and safe: later steps can post the transaction link.

Action statuses

API

Creating and verifying a grant needs a wallet session; listing and revoking also work with an API key. See API.