Allow for conditional function arguments when calling wallet_grantPermissions.

[Fbartoli]

🧩 Current Design

The wallet_grantPermissions function currently supports the following structure for defining authorized smart contract calls:

calls: {
  /** Function signature or 4-byte signature. */
  signature?: string;
  /** Authorized target address. */
  to?: `0x${string}`;
}[]

This allows scoping based on function signature and target contract, but does not allow for controlling function arguments.

🚫 Problem

This structure permits calls to a function like approve(address,uint256) for any address and any amount — which is too permissive for many use cases.

In scenarios like automated trading or delegated execution, finer-grained control is needed. For example:

Approving only a specific address as spender.
Capping the maximum token amount approved.
✅ Proposed Enhancement

Extend the calls structure with an optional args field to add argument-level conditions:

// Represents all available condition operators
type ConditionOperator =
  | 'equal'
  | 'greater_than'
  | 'less_than'
  | 'greater_than_or_equal'
  | 'less_than_or_equal'
  | 'not_equal'
  | 'in_range';

type Condition =
  | {
      operator: 'equal' | 'greater_than' | 'less_than' | 'greater_than_or_equal' | 'less_than_or_equal' | 'not_equal';
      value: bigint | `0x${string}` | boolean;
    }
  | {
      operator: 'in_range';
      min: number;
      max: number;
    };

type Call = {
  signature?: string;
  to?: `0x${string}`;
  args?: {
    position: number; // 0-based position in the function signature
    condition: Condition;
  }[];
};

🎯 Example Use Case

Let’s say a user wants to allow a bot to perform trades on their behalf using the Li.Fi aggregator.

The user grants permission to call approve(address,uint256) on ERC-20 tokens, but only:
If spender == LiFiAggregatorAddress
And amount <= MAX_APPROVAL_LIMIT
The bot then:
Gets ERC-20 approval with a safe cap
Executes the trade through LiFi

calls: [{
  signature: 'approve(address,uint256)',
  args: [
    {
      position: 0,
      condition: {
        operator: 'equal',
        value: '0xLIFI_AGGREGATOR_ADDRESS'
      }
    },
    {
      position: 1,
      condition: {
        operator: 'less_than_or_equal',
        value: BigInt('1000000000000000000') // 1 token
      }
    }
  ]
}]

🛡️ Benefits

Enables fine-grained, secure delegation.
Reduces trust surface for delegated key holders.
Prevents misuse of generic approve() calls.
Facilitates safer bot-driven DeFi automation.

The above is just an implementation idea to illustrate the point.

[tuler]

I also have a use case for this. A permission could be granted to add inputs just to an specific Cartesi application by limiting the scope of the InputBox.addInput call for a particular appContract.

Just for comparison, ZeroDev Kernel CallPolicy supports this with the following structure. source code

// An array of conditions, each corresponding to an argument for
// the function.
args: [
  {
    condition: ParamCondition.EQUAL,
    value: value,
  },
],

args: an array of conditions, each corresponding to an argument, in the order that the arguments are laid out. use null to skip an argument.

operator: this can be EQUAL, GREATER_THAN, LESS_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN_OR_EQUAL, NOT_EQUAL.
value: the value of the argument to use with the operator. For instance, operator = EQUAL and value = 2 would mean "the argument must be equal to 2".

[jxom]

For your cases, is the app permitting itself to sign? or is the app permitting a key that belongs to a third-party (that will sign)?
For the former, it's kind of behaviorally hard to do call scopes (and even narrow them like this), because there is no way to humanly express these call scopes to an end-user to sign over. So nothing is stopping an app from going as widened as they want.
For the latter, I understand that this could be beneficial.

Alternative could be to add a spender property to our spend permissions which will narrow the scope of the spender on the approval. However, that doesn't solve for @tuler's use case.

[Fbartoli]

In my case it would a specified key own by a third party.
Let's assume some kind of back-end system with an ecdsa key.

[jxom]

If we were to go down comparison operator approach, I would envision an API for this similar to how we describe arguments when invoking contract calls in Viem, however, instead represent the respective values as a tuple of [operator, value]. We can also define strict types via ABIType to get some nice type inference & validation here based on the signature.

Operators

Operator	Supported Operand ABI Types	Description
= , !=	bool, (u)int, string, bytes, address	JS strict equal (===) semantics
< , <=, >, >=	(u)int	JS number compare semantics

Note: items inside solidity tuples and arrays will not support operands for now.

Definition

type CallPermissions = {
  signature?: string | undefined,
  to?: string | undefined,
  args?: [operator: "=", "!=", "<", "<=", ">", ">=", value: unknown][]
}[]

Usage

// Case 1: Valid args
wallet_grantPermissions({
  permissions: {
    calls: [{
      signature: 'approve(address, uint256)',
      args: [null, ['<', 1_000n]]
    }]
  }
})

// Case 2: Invalid value type
wallet_grantPermissions({
  permissions: {
    calls: [{
      signature: 'approve(address, uint256)',
      args: [null, ['<', 'foobar']]
//                        ^? Type 'string' is not assignable to type 'bigint'.
    }]
  }
})

// Case 3: Invalid operator type
wallet_grantPermissions({
  permissions: {
    calls: [{
      signature: 'approve(address, uint256)',
      args: [['<', '0x...']
//             ^? Type '"<"' does not satisfy the expected type '"=" | "!="'
    }]
  }
})

[Fbartoli]

That would be really great to have type inference for sure.