> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/guides/transactions/contract-operations.md). # Contract operations How to call a function on a smart contract, and how to deploy a smart contract, from an Ethereum or EVM Account on Ledger Enterprise. This page describes the two contract operations: a contract interaction calls a function on a smart contract, and a contract deployment publishes a new one. **Role: Operators.** You must be in the **Request initiator** step of the Rule for the operation. A Master Administrator adds that Rule to the Account. Both operations are available on native Accounts on Ethereum and the EVM networks. A token Account has no contract operations. Each operation is a **Request**, governed by its own Rule and approved like a transfer. Through the API, an API user creates contract Requests without the interface. See the [API documentation](https://help.enterprise.ledger.com/api-documentation-v2). ## The Rules that govern them Each operation has its own Rule type, separate from the Send Rules. An Account that can send cannot necessarily call or deploy a contract. | Rule | API operation type | Amount threshold applies to | Whitelists | | ----------------------------- | ------------------ | ------------------------------------ | --------------------------------------------------------------- | | **Contract Interaction Rule** | `EXECUTE_CONTRACT` | The native value that the call sends | Smart Contract Whitelists, matched against the contract address | | **Contract Deployment Rule** | `DEPLOY_CONTRACT` | The initial deposit | None | A Rule matches when all of these are true: * The amount is inside its threshold. * The contract is in one of its Whitelists, when the Rule has any. * You are in its **Request initiator** step. See [**Creating and editing Accounts**](/help-center-v2/guides/accounts/creating-and-editing-accounts.md) and [**Whitelists**](/help-center-v2/administration/governance/whitelists.md). > **Important:** The threshold of a Contract Interaction Rule covers only the native value that the call sends. It does not cover tokens that the contract moves. A call to a non-payable function, such as an ERC-20 `transfer` or `approve`, sends a value of 0. It matches a Rule whose threshold includes 0, whatever the token amount. ## Interact with a contract ### Start the interaction 1. On the Account page, open the menu next to **Send**. 2. Select **Interact with contract**. The **Contract interaction** page opens. You can also open it from the menu on the Account's row in the Accounts list. The menu lists **Interact with contract** only when you are in the **Request initiator** step of a Contract Interaction Rule on the Account. ### Enter the contract address Enter the contract in **Address**. The Whitelists of your Contract Interaction Rules decide what you can enter: | Your Account's Contract Interaction Rules | What you can do | | ----------------------------------------- | ------------------------------------------------------------- | | Every Rule has a Whitelist | Select a whitelisted contract. You cannot type a free address | | Only some Rules have a Whitelist | Select a whitelisted contract, or type an address | | No Rule has a Whitelist | Type an address | ### Read the Clear Signing notice When you enter the address, the form checks whether the contract supports Clear Signing. With Clear Signing, the Ledger device can show the decoded call: the function and its parameters. The form shows one of two notices: * "Clear signing is supported on this contract" * "Clear signing not supported on this contract" Without Clear Signing, the transaction is blind signed: the Ledger device cannot decode the call. The notice does not block **Review**. If the check cannot complete, the form shows no notice. The notice is for the contract, but Clear Signing applies function by function. A call to a function that the contract's Clear Signing data does not cover is blind signed. The Clear Signing data of a contract comes from Ledger, not from your Workspace. To ask for Clear Signing on a contract, contact Ledger Support. ### Choose the function The form fetches the contract's Application Binary Interface (ABI) from the address. The ABI is the list of the contract's functions and their parameters. The form shows **Fetching the ABI**, then **ABI fetched**. Select **Show ABI** to read it. If the ABI cannot be fetched, the form shows "ABI couldn't be fetched. Please copy an ABI below to proceed." Paste the ABI, in JSON, in the **ABI** field. For a proxy contract, the form opens on the functions of the implementation contract. Select **Back to Proxy ABI (basic functions)** to use the functions of the proxy contract itself. Select **Access all functions (implementation)** to return. 1. In **Contract method**, select the function. The list leaves out read-only (`view`) functions. 2. Enter a value in the field for each parameter. A tuple or an array takes JSON. A `bool` takes `true` or `false`. 3. If the function is payable, enter the amount to send in the **value** field, for example **ETH value**. To give the call as raw data, select **Use Raw Calldata Input**. Enter the hex-encoded call, starting with `0x`, in **Transaction Calldata (Hex-encoded)**. In this mode, the **value** field is always shown. Select **Switch back to Select Function** to return to the function list. ### Add a note and check the fee The **Note (optional)** field takes up to 1,000 characters. It is the only context that an Approver sees on the Request. The fee appears when the address and the call are complete. It is a maximum, like the fee of a transfer. See [**Transaction fees**](/help-center-v2/reference/transaction-fees.md). ### Check the Transaction Check result Transaction Check screens the call before you create the Request. Its result shows under the fee, and **Review** stays unavailable until the check is complete. A flagged result needs your acknowledgement when you select **Review**. See [**Transaction Check**](/help-center-v2/guides/transactions/sending-assets.md#transaction-check). ### Approve the interaction 1. Select **Review**. 2. If Transaction Check flagged the call, read the result. Select **Proceed** to continue, or **Cancel** to stop. 3. Confirm the details on your Ledger device. The Request then collects the approvals that its Rule requires. > **Important:** The form does not name the matching Rule, unlike the send form. If no Contract Interaction Rule covers the value, the contract and you, the platform refuses to create the Request. ### After the Request is created The Request details show the call decoded: the function name, the contract address, and the **Parameters** with their values. If the call cannot be decoded, the details show the **Transaction calldata (HEX)**. A contract interaction cannot be sped up or canceled after it is broadcast. See [**Ethereum and EVM networks**](/help-center-v2/reference/networks/ethereum.md). ### Tokens that a call moves A contract call can move tokens, for example in a swap. The call appears as **Contract interaction** on the **Operations** tab of the Account that made it. Each token movement appears on the **Operations** tab of the token Account for that token. It shows as **Send** or **Receive** when the call is an ERC-20 `transfer` or `transferFrom`. Any other call shows as **Contract interaction**. A token that has no token Account shows on the **Token accounts** tab with the **View only** tag. See [**Tokens received without a token Account**](/help-center-v2/guides/accounts/finding-accounts-and-balances.md#tokens-received-without-a-token-account). ## Deploy a contract The menu lists **Deploy contract** only when you are in the **Request initiator** step of a Contract Deployment Rule on the Account. 1. On the Account page, open the menu next to **Send**. 2. Select **Deploy contract**. 3. In **Contract bytecode**, paste the compiled bytecode of the contract. It must be a hex string that starts with `0x`. 4. Optional: in **Value / Initial deposit (optional)**, enter an amount to send to the new contract. 5. Optional: add a note. 6. Check the matching Rule that the form names. 7. Enter the fee fields. 8. Select **Review**. 9. Confirm the details on your Ledger device. ### Set the fee manually The form does not estimate the fee for a deployment, and it offers no speed choice. It shows "Please enter the fee manually. You can use an external tool to estimate it." Enter all three fields: | Field | What it sets | | ----------------------- | -------------------------------------------------------------------------- | | **Gas price (Gwei)** | The maximum price for each unit of gas | | **Gas limit** | The maximum number of gas units. A whole number | | **Priority fee (Gwei)** | The tip for each unit of gas. More than 0, and not more than the gas price | The form shows the **Max fee**: the gas price multiplied by the gas limit. ### After the Request is created The Request details show the **Deployer account** and the **Contract bytecode hash**, a Keccak-256 hash of the bytecode. They do not show the bytecode itself. Transaction Check does not apply to a deployment. A deployment cannot be sped up or canceled after it is broadcast. ## Limiting web3 exposure **Role: Master Administrators.** A contract call acts with the address of the Account that makes it. The controls below limit what a call can reach. | Control | What it limits | | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | No Contract Interaction Rule and no Contract Deployment Rule on the Account | The Account cannot call or deploy a contract. A dapp transaction is a contract interaction, so the Account cannot make one either | | No Message Signing Rule on the Account | The Account cannot sign messages, from the form or from a dapp | | A Smart Contract Whitelist on every Contract Interaction Rule | Calls go only to the listed contracts. Operators cannot type a free address | | A separate Account for contract operations | A call can reach only the assets at that Account's address. These are its native balance and the tokens of its token Accounts | | The approval steps of the Contract Interaction Rule | Each call collects its own approvals, separate from those of the Send Rules | | Transaction Check | Each call is screened before its Request is created, and again before signature | The amount threshold of a Contract Interaction Rule does not limit token movements. See [The Rules that govern them](#the-rules-that-govern-them). > **Warning:** An ERC-20 `approve` call gives a spender an allowance on the token. The spender can then move tokens up to that allowance from the Account's address, with no new Request. The allowance stays until a later call changes it. See the [ERC-20 standard](https://eips.ethereum.org/EIPS/eip-20) (checked on 9 October 2026). ## What can go wrong | What you see | Why | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Interact with contract** or **Deploy contract** is not in the menu | You are not in the **Request initiator** step of a Rule for that operation on this Account. A Master Administrator must add you | | The address is invalid | The contract address is not a valid address | | ABI couldn't be fetched. Please copy an ABI below to proceed. | The form could not find the contract's ABI. Paste it in the **ABI** field | | Invalid ABI | The pasted ABI is not valid JSON in ABI format | | No methods available | The ABI has no function that you can call | | Invalid *type* value, for example "Invalid uint256 value" | A parameter value does not match its type | | Transaction Calldata must be a valid hex-encoded string | The raw calldata is not hex, or it does not start with `0x` | | Amount exceeds your available balance | The value to send is above the available balance | | Contract bytecode must be a valid hex string starting with 0x | The bytecode is not hex, or it does not start with `0x` | | Priority fee must not exceed gas price | The priority fee is above the gas price | | Priority fee must be a positive number | The priority fee is 0 | | Insufficient balance to cover the fee, or to cover the fee and deposit | The maximum fee, plus any deposit, is above the available balance. This is a warning, and it does not block **Review** | | No matching rule found for the given amount | No Contract Deployment Rule covers this deposit for you | | The Request is not created after **Review** on a contract interaction | No Contract Interaction Rule covers this value and contract for you | ## Related * [**Sending assets**](/help-center-v2/guides/transactions/sending-assets.md) * [**Connect**](/help-center-v2/guides/connectivity-hub.md) * [**Ethereum and EVM networks**](/help-center-v2/reference/networks/ethereum.md) * [**Whitelists**](/help-center-v2/administration/governance/whitelists.md) * [**How governance works**](/help-center-v2/concepts/how-governance-works.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.enterprise.ledger.com/help-center-v2/guides/transactions/contract-operations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.