Cross-Contract Calls in Near Protocol
Tags: rust, near, tutorial, contract
Published: 2022-02-12 22:16:35

**Initial clarifications:**

- The following article is focused on the development of smart contracts using Rust.
- Although the examples are developed in NEAR, much of the following information can be transposed to any other blockhain where it can be developed using Rust.
- The examples are taken from the following repository: [BlockJobs-Marketplace](https://github.com/NEAR-Hispano/mkt-servicios-profesionales), where several cross-contract calls can be seen in addition to those used below.
- This article shows a cross-contract call from a professional services marketplace, to the DAI contract, to allow payments for services in DAI or others fungible tokens.

**Introduction:**

There are various reasons for requiring calls between contracts, such as requesting and/or modifying information, using code from a third-party contract without copying it, transferring tokens, etc. and this can be done by working in a similar way to how API calls work.
An example of this is shown below, providing a contextual explanation of how a cross-contract call works.

**1- Calling contract**

To be able to call an external function, the first thing to do is to indicate to our contract what information the function that will be called requires, specifying parameters with their respective data types (in several contracts it is seen that `&self` is added and the type of data to return, but this can be omitted). For this you must first import `near_sdk::ext_contract` and implement it as shown below.

```
use near_sdk::ext_contract;

impl Contract {
   …
}

#[ext_contract(ext_contract)]
trait ExtContract {
fn ft_transfer(&mut self, receiver_id: AccountId, amount: U128, memo: Option<String>);
}
#[ext_contract(ext_self)]
pub trait ExtSelf {
    fn on_buy_service(service_id: u64) -> Service;
}
```

- The 'ext_contract' in parentheses is the name that is being given and will then be used to indicate which trait is being called, since more than one can be set in order to have a better order.
- 'ExtContract' is a name that is not required later, that is, it is indifferent.
- If the function that is called or not, is public, it is also indifferent, placing 'ft' is enough.
- The name of the function and the parameters must be exactly the same as those of the contract that is called, in the event of any typing error we will receive an "insufficient gas amount" error.
- The trait ExtSelf will be explained later.

**1.1 - Make the call**

Within the corresponding function, the call is made as follows:

```
ext_contract::ft_transfer(
   self.contract_me.clone(),
   service.metadata.price.into(),
   None,
   &token, 
   ONE_YOCTO, 
   GAS_FT_TRANSFER
).then(ext_self::on_buy_service(
   service_id,
   &env::current_account_id(), 
   NO_DEPOSIT, 
   BASE_GAS)
);
```

- `ft_transfer` is being called passing first the 3 corresponding parameters, then the address of the contract (the DAI address must be passed in this case, which is assigned to `token`), then the amount of NEAR attached to the in the case of a payable type function and finally the amount of gas, a topic that will be expanded on later. The order of the parameters must be strictly respected, otherwise it will fail and the compiler does not always show an error.
- The deposit and the gas are in this case assigned in constants, but the numerical value can also be specified directly.
- The `then` method can be omitted, it is used in the case of wanting to execute a second function depending on what the called function returns, this is shown in more detail below.

**1.2 - Call back**

A second function can be created in the contract that makes the call, which, based on what is returned, executes certain actions. It is not strictly necessary but it is normally called with an on preceding the name of the first function, in the example case the function from which it is initially called is `buy_service`, so now the name will be `on_buy_service` and is given by the following code:

```
pub fn on_buy_service(&mut self, service_id: u64) -> Service {
  match env::promise_result(0) {
      PromiseResult::Successful(_data) => {
          service.sold = true;
          service.on_sale = false;
          self.service_by_id.insert(&service_id, &service);
          return service;
      }
      PromiseResult::Failed => env::panic(b"Callback faild"),
      PromiseResult::NotReady => env::panic(b"Callback faild"),
  };
}
```

- In the event of an error in the call, a panic type error is executed with the message "Callback failed", if the call has been executed correctly, the code that modifies the state of the contract that initially calls is executed (this could done directly in the first function without the `then` method, but this is good practice.
- In this case, the value that is returned is not being used, which is why the `data` parameter has a "_" in front of it, preventing a warning from being issued, but this value could be necessary for the status modification.
- In the initially shared repository you can also see examples where this is omitted.
- Although it is not used in this example, it can be useful to return a promise, for which `near_sdk::PromiseOrValue` must be imported, in this [link](https://docs.rs/near-sdk/ 2.0.0/near_sdk/enum.PromiseOrValue.html) expands on this topic.

**2 - Called contract**

The called contract can be one of its own or another, it is only necessary to know the address and the method to call with its parameters.
In the example case, the transfer function of the DAI contract is being called, so if the transfer is executed correctly, `on_buy_service` is subsequently executed and the status modified as indicated. However, the returned value could be other data such as a boolean for example and from this modify the information. In the example code you can see this by going to the `validate_user` and `validate_tokens` functions, both of which are in the `mediator.rs` contract.

**3 - Gas Management**

The most common error is "Insufficient gas amount", which can be due to an insufficient amount of gas set or attached, but also due to an error that prevents the called function from finishing executing and returning a result. In the event that this happens, it may be a good idea to issue logs at the beginning and end of each function to see how far the execution is carried out and also to comment the code where state changes are made to verify if the problem is in the call or in the internal code of some of the functions.
If the error is not found by performing the aforementioned, it may be that an amount of gas greater than the maximum supported by Near, which is 300 Tgas, is being established, if in the example 200 Tgas had been passed as a parameter to execute `ft_transfer` and 120 Tgas for `on_buy_service`, those 300 would never be enough, or in the case of working on testnet, it may be that not enough gas is being attached. For testing it may be advisable to specify the maximum amount of gas by adding `--gas 300000000000000` to the end of the function call. Then the remaining gas is returned to the person who signs the transaction, but if you prefer this value can be adjusted by seeing how much gas is consumed, it is advisable to always indicate a higher amount, perhaps twice as much to ensure that it is not insufficient.

**Final clarifications**

- Remember that it is advisable to write tests for the functions and the calls between contracts that are made.
- To view information pertaining to gas usage and the values ​​returned by the functions, you can use [Near Explorer](https://explorer.near.org/).
- For questions, we recommend [StackOverflow](https://stackoverflow.com/questions/tagged/nearprotocol), or the [Telegram channel for devs](https://t.me/neardev).

I hope this information has been useful to you.