Call Your Contract

Now that your contract has been fully deployed, we can start interacting with it! Flipper only has two functions: flip() and get(). We will show you what it's like to play with both of them.

When you deployed your contract you received the contract address. Use this to interact with the contract.

Contract Address: 0x4172ec94a05289f9ec332867a3b93ae31d18c593

Choose your preferred method to call your contract:

Pop

Pop CLI provides a simple way to interact with your deployed contracts.

Interactive

pop call contract

Manual: read contract state (get() function)

pop call contract
  --contract <insert-contract-address>
  --message get
  --suri //Alice

Manual: modify contract state (flip() function)

pop call contract
  --contract <insert-contract-address>
  --message flip
  --execute
  --suri //Alice

For more detailed information about Pop CLI contract interaction, see the Pop CLI call guide.

cargo-contract

Read contract state (get() function)

cargo contract call 
  --contract <insert-contract-address> 
  --message get 
  --suri //Alice

Modify contract state (flip() function)

cargo contract call 
  --contract <insert-contract-address>
  --message flip
  --execute
  --suri //Alice

Contracts UI

Go to https://ui.use.ink/

Read contract state (get() function)

We set the initial value of the Flipper contract value to false when we instantiated the contract. Let's check that this is the case.

In the Message to Send section, select the "get(): bool" message and accept the default values for the other options.

Press "Read" and confirm that it returns the value false:

Modify contract state (flip() function)

So let's make the value turn true now!

The alternative message to send with the UI is flip(). Again, accept the default values for the other options and click Call contract

If the transaction was successful, we should then be able to go back to the get() function and see our updated storage:

RPC calls vs. Transactions

There are two ways of calling a contract:

Dry-run via RPC

Remote procedure calls, or RPC methods, are a way for an external program – for example, a browser or front-end application – to communicate with a Polkadot SDK node. For example, you might use an RPC method to read a stored value, submit a transaction, or request information about the chain a node is connected to.

If a user interface displays the value of a contract (e.g. the balance of an account in an ERC-20 contract), then this is typically done via RPC. Specifically it is done by executing a synchronous dry-run of the contract method and returning its result. The following schema depicts this.

RPC calls don't require any tokens, they just require a connection to a node in the network. It's important to note that the execution won't result in any state mutations on the blockchain, it really just is a dry-run.

State mutating via submitting a Transaction

The other method of executing a call to a contract is by submitting a transaction on-chain. This requires tokens of the network to pay for the cost of the transaction. The transaction will be put in a transaction pool and asynchronously processed. The important implication here is that during submission of the transaction no result is available. This is different from an RPC call.

The typical pattern for how a client can recognize the result of the contract call is to have the contract emit an event and have the client actively listen for such an event. Typically libraries (like polkadot-js/api) provide API functions to do just that. The important take-away is that contract developers have to make sure that events are emitted if they want clients to be able to pick up on them.