Skip to main content

Invoking Smart Contracts

The Call operation within the L2 transaction block is the one that executes/invokes/calls a smart contract in Coinweb's L2 computer.

export interface CwebCall {
resources: CompResources;
smart_contract: ContractRef;
number_of_arguments: number;

The extracted interface above reveals that the operation provides the smart_contract reference in order for the L2 computer to locate and process it in Coinweb. Further it indicates resources and the number_of_arguments. The parameters are described more closely below.


The Coinweb VM is the actual machine that executes a smart contract. By providing the resources field you can control which kind of VM shall be used.


Currently supported resources for the Coinweb VM is only SmallWasmInstance.

Number of Arguments

The number of arguments describes the count of subsequent Coinweb operations after a CallOp, in which every following operation after the call becomes a contract argument. This argument is equivalent to a ResolvedOperation, which can be parsed using getContractArgument. This parameter is important for the composition of operations in a smart contract invocation. These subsequent operations are also referred to as slices.


Assuming an arbitrary CallOp includes subsequent slices in the following order: Call, Read, Read, Data, Store. The initial CallOp will be treated as the 0 argument, and the number_of_arguments becomes 4 (1. ReadOp, 2. ReadOp, 3. DataOp, 4. StoreOp ).

Contract Reference

The contract reference (v0) represents how to construct the virtual file system (VFS) for the contract. There are two ways to do this, either by referencing stored claims that include the VFS information, or explicitly by providing raw data in the form of a [ContractTree]. The explicit approach is typically used when first invoking a contract (see the self registration system), potentially combined with also using stored claims for parts of the VFS that can be reused from other parts of the system.


If a smart contract is executed in a WASM interpreter, which is also used by other smart contracts, it is not necessary to (re-)deploy it for each contract. It can be published once and further referenced in other smart contracts utilising a ReadOp operation.

Virtual file system and its components are deeper described in the upcoming chapters.

The following excerpt from the contract-kit SDK exemplarily shows how a smart contract reference is constructed.
export type ContractIssuer = {
FromSmartContract: ContractId;

export type ContractRef = {
stored: CwebRead[];
explicit: ContractTree;

export interface ResolvedContractRef {
contract_id: HashId;
resolved: ContractTreeResolved;

export function contractRef(
issuer: ContractIssuer,
explicit: ContractTree
): ContractRef {
return {
stored: [{ Claim: { issuer, key } } as SingleClaimRead],

The contract_id is a function of the ResolvedContractRef and therefore can be reconstructed from the resolved reference object.