Skip to main content
Note: see the language section for more details.

Overview

Tempo transactions are fully parsed by the policy engine via the tempo.tx namespace. Tempo natively supports batched calls — a single transaction can contain multiple calls that execute atomically. The tempo.tx.calls list gives you granular access to each call’s destination, input data, and function selector.

Transaction-level policies

Allow Tempo transactions

Restrict to a specific chain ID

Allow specific fee token

Deny Tempo transactions

Cap gas limit

Cap max fee per gas

Restrict validity window

Call-level policies

Tempo transactions contain one or more calls in tempo.tx.calls. You can target individual calls by index or use quantifiers (all, any) to apply rules across all calls.

Allow calls to a specific contract

Allow ERC-20 transfer function selector

Deny a specific call destination

Deny single-call transactions (require batching)

Batch call policies with quantifiers

Allow only when all calls target an approved address

Allow only when all call destinations are known addresses

Raw calldata inspection

Since Tempo does not support Smart Contract Interfaces (ABI parsing), you can use slicing on tempo.tx.calls[i].input to inspect encoded arguments directly. The input field is case-insensitive, so hex comparisons work regardless of casing. In standard ABI encoding, each argument occupies a 32-byte (64 hex character) word. The function selector occupies the first 4 bytes (8 hex characters, plus the 0x prefix), so the first argument word starts at position 10. For an address argument, the address value itself starts at position 34, because it is right-aligned within the 32-byte word and preceded by 12 bytes (24 hex characters) of left-padding. Each subsequent argument word starts 64 hex characters later.

Restrict ERC-20 transfer recipient via calldata

This example allows an ERC-20 transfer(address,uint256) only when the recipient (first ABI argument) matches a specific address:

Verify calldata recipient address

Combine calldata slicing with an address comparison to ensure the encoded recipient matches an expected address:

Verify both from and to in transferFrom calldata

For transferFrom(address,address,uint256), the from is the first argument (positions 34..74) and to is the second (positions 98..138):

Wallet and key scoping

These policies work the same as other blockchain types — you can combine tempo.tx conditions with wallet, private key, and consensus rules.

Allow Tempo transactions for a specific wallet

Allow Tempo transactions for a specific private key

Require specific approver for Tempo transactions

Allow Tempo transactions for wallets with a specific label

Allow Tempo transactions for private keys with a specific tag

Legacy Ethereum transactions on Tempo

During Tempo’s testnet period, legacy Ethereum transactions are also supported on Tempo and can be governed using standard Ethereum policy syntax. See the Ethereum policy examples for more details on how to write policies for these transaction types.