Tempo examples

Tempo transactions carry fields that don’t exist on standard EVM transactions. The tempo_transaction field source exposes these fields, giving policies control over Tempo-specific intents: fee token selection, transaction sponsorship, and validity windows.

Standard ethereum_transaction conditions (to, value, data, and others) are enforced against all transactions on Tempo. Use tempo_transaction conditions on top of these to gate on Tempo-specific fields that don’t exist on standard EVM transactions. Both field sources can be combined in the same rule. See Ethereum examples for the full set of available ethereum_transaction fields.

Require a specific fee token

Use this policy when your app controls the gas token. For example, to ensure all transactions pay fees in your app’s stablecoin rather than whichever token a wallet happens to hold.

{
    version: '1.0',
    name: 'Restrict fee token to pathUSD',
    chain_type: 'ethereum',
    rules: [{
        name: 'Only allow pathUSD as fee token',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'tempo_transaction',
                field: 'fee_token',
                operator: 'eq',
                value: '0x<pathUSD contract address>'
            }
        ],
        action: 'ALLOW'
    }]
}

The in operator supports multiple allowlisted fee tokens:

{
    version: '1.0',
    name: 'Allowlist fee tokens',
    chain_type: 'ethereum',
    rules: [{
        name: 'Allow pathUSD or USDC as fee token',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'tempo_transaction',
                field: 'fee_token',
                operator: 'in',
                value: ['0x<pathUSD address>', '0x<USDC address>']
            }
        ],
        action: 'ALLOW'
    }]
}

Require sponsored transactions only

Use this policy when your app sponsors gas for all users. It prevents wallets from submitting unsponsored transactions that would fail due to insufficient gas funds.

{
    version: '1.0',
    name: 'Require sponsorship',
    chain_type: 'ethereum',
    rules: [{
        name: 'Only allow transactions with a fee payer signature',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'tempo_transaction',
                field: 'fee_payer_signature',
                operator: 'eq',
                value: 'true'
            }
        ],
        action: 'ALLOW'
    }]
}

Block sponsored transactions

Use this policy when wallets should always self-pay for gas. It prevents third-party fee payers from fronting costs, which can be useful for compliance or cost-control reasons.

{
    version: '1.0',
    name: 'Block sponsored transactions',
    chain_type: 'ethereum',
    rules: [{
        name: 'Deny transactions with a fee payer signature',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'tempo_transaction',
                field: 'fee_payer_signature',
                operator: 'eq',
                value: 'true'
            }
        ],
        action: 'DENY'
    }]
}

Time-bound a validity window

Use these conditions to limit when transactions can be executed, such as requiring transactions to become valid after a future timestamp or expiring transactions that are not broadcast promptly.

These fields control when the chain accepts a transaction, not when Privy broadcasts it. valid_before and valid_after are enforced by Tempo at execution time. This is distinct from time-bound policies, which restrict when Privy will sign or send a transaction.

valid_before and valid_after take Unix timestamps in seconds. Unset fields evaluate as false (no constraint). The value in a condition is a static timestamp computed at policy creation time. The example below computes a cutoff 5 minutes in the future.

const fiveMinutesFromNow = String(Math.floor(Date.now() / 1000) + 300);
const policy = {
  version: '1.0',
  name: 'Enforce 5-minute transaction expiry',
  chain_type: 'ethereum',
  rules: [
    {
      name: 'Only allow transactions expiring within 5 minutes of policy creation',
      method: 'eth_sendTransaction',
      conditions: [
        {
          field_source: 'tempo_transaction',
          field: 'valid_before',
          operator: 'lte',
          value: fiveMinutesFromNow
        }
      ],
      action: 'ALLOW'
    }
  ]
};

Both fields together define a strict validity window:

{
    version: '1.0',
    name: 'Strict validity window',
    chain_type: 'ethereum',
    rules: [{
        name: 'Transaction must be valid within business hours window',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'tempo_transaction',
                field: 'valid_after',
                operator: 'gte',
                value: '1757300000'
            },
            {
                field_source: 'tempo_transaction',
                field: 'valid_before',
                operator: 'lte',
                value: '1757386400'
            }
        ],
        action: 'ALLOW'
    }]
}

Restrict nonce key

Tempo supports 2D nonces via nonce_key. A value of 0 uses the protocol-managed sequential nonce; values above 0 are user-managed nonces that allow parallel transaction submission across independent lanes. Use this policy for apps where transactions must execute in submission order. For example, an approve followed by a transferFrom will fail if the transfer lands first. For trading apps, an out-of-sequence limit order or a sell that lands before a buy produces incorrect results. Forcing nonce_key to 0 guarantees strict ordering at the cost of throughput. This policy forces all transactions to use the protocol nonce:

{
    version: '1.0',
    name: 'Protocol nonce only',
    chain_type: 'ethereum',
    rules: [{
        name: 'Restrict to protocol-managed nonce',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'tempo_transaction',
                field: 'nonce_key',
                operator: 'eq',
                value: '0x0'
            }
        ],
        action: 'ALLOW'
    }]
}

Composite rule: fee token and recipient

tempo_transaction and ethereum_transaction conditions can be combined in a single rule. All conditions must pass for the rule to match.

{
    version: '1.0',
    name: 'Controlled payments to allowlisted addresses',
    chain_type: 'ethereum',
    rules: [{
        name: 'Allow only to known recipients and with approved fee token',
        method: 'eth_sendTransaction',
        conditions: [
            {
                field_source: 'ethereum_transaction',
                field: 'to',
                operator: 'in',
                value: [
                    '0xRecipientAddress1',
                    '0xRecipientAddress2'
                ]
            },
            {
                field_source: 'tempo_transaction',
                field: 'fee_token',
                operator: 'eq',
                value: '0x<pathUSD contract address>'
            }
        ],
        action: 'ALLOW'
    }]
}

Policies

Using policies

Examples

Require a specific fee token

Require sponsored transactions only

Block sponsored transactions

Time-bound a validity window

Restrict nonce key

Composite rule: fee token and recipient

​Require a specific fee token

​Require sponsored transactions only

​Block sponsored transactions

​Time-bound a validity window

​Restrict nonce key

​Composite rule: fee token and recipient

Require a specific fee token

Require sponsored transactions only

Block sponsored transactions

Time-bound a validity window

Restrict nonce key

Composite rule: fee token and recipient