I am trying to implement a Java interface to be able to call FA1.2 smart contract entrypoints programmatically. This is what I've got now:

public interface FA12
   public JSONObject transfer(String from, String to, Integer value) throws Exception;
   public JSONObject approve(String spender, Integer value) throws Exception;
   public JSONObject getAllowance(String owner, String spender) throws Exception;
   public JSONObject getBalance(String owner) throws Exception;
   public JSONObject getTotalSupply(Integer total) throws Exception;

But I was told that these get operations should not return a value. Instead, I should use callbacks to get the results: Apparently I should call a VIEW entrypoint and supply to the view an address and a callback contract. That's not something trivial, even for an experienced developer as I am. What callback contract address should I use? One that I have deployed my own? All contracts have its own callback contract address?

I am having some difficulty while trying to understand the correct way to do it.

My goal here is just calling getBalance() to check how many tokens an address has in a mainnet deployed contract.

Please, any help will be appreciated. Thanks in advance.

2 Answers 2


You are correct. There is not a way to get the value directly. You would have to originate a contract like this. Let's call it getnat.tz. We will use it to create an error message after a dry run call.

parameter (nat);
storage unit;
code { CAR; FAILWITH };

Now we can call it from the client.

tezos-client transfer 0 from alice to token \
             --entrypoint 'getBalance' \ 
             --arg 'Pair "<token-owner-address>" "<getnat-address>"' \

This will produce an error message with the value. You will have to parse it. If you add the -l flag you can see the RPC routes that tezos-client calls to recreate it in your application.

  • Won't this cause a space issue in Tezos blockchain sooner or later? I mean, each call to a contract entrypoint will build a new contract to receive an answer? Seems odd to me. Commented Jun 16, 2020 at 17:13
  • 1
    It is possible with one contract but it requires a tool that generates some lambda code for you. Take a look at this github.com/tqtezos/lorentz-contract-view
    – MCH
    Commented Jun 16, 2020 at 17:25
  • The --dry-run parameter avoid actual contract deployment to the blockchain, right? Is there a parallel using an RPC call? Commented Jun 16, 2020 at 23:10
  • 1
    Right. We actually only need on contract deployed for everyone to use. It is detailed in that github repo. Then the dry run calls to it are free. Yes, the tezos-client interacts with the blockchain via the RPC. Use the -l flag to see what is being called and you can imitate it.
    – MCH
    Commented Jun 17, 2020 at 1:12

After talking to many active Tezos community members, I have finally found a solution:

public interface FA12
   public void transfer(String from, String to, Integer value) throws Exception;
   public void approve(String spender, Integer value) throws Exception;

Which means that I only need to implement the contract calls that actually do an action (like transfer and approve). All other entrypoints that require a "VIEW" type, like getBalance, getAllowance or getTotalSupply are entrypoints to be called between contracts. In my case I can check all information I need by parsing the contract STORAGE, so I can avoid the hurdles associated with dummy contracts created to serve as a callback for responses.

  • If you know the storage of a particular FA1.2 contract, then you can try to read it, but the standard does not mention any requirement of having storage of a particular shape so you cannot trust the storage for any random FA1.2. The reason is the author of an FA1.2 contract may decide that the total supply increases/decreases over time or change for some other condition. A contract does not update itself but getBalance should calculate the value at the time it is called.
    – MCH
    Commented Jun 16, 2020 at 21:37
  • Hmmm. I see. That sends me a step backwards... So getBalance implementation seems to be needed. And so does that trickery with a dummy callback contract... Commented Jun 16, 2020 at 22:50
  • 1
    In the short term that is the solution. In the long term you could talk to community members and core developers to gather interest in changing Tezos so that this work around is not necessary.
    – MCH
    Commented Jun 17, 2020 at 1:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.