info

The explanation on this page assumes you have a certain level of understanding of blockchain technology.

Related information

• Smart Contracts are invoked by a Call operation during execution of a transaction in the Coinweb Virtual Machine.
• Smart Contracts are executed in smart contract virtual machines where Web Assembly(WASM) is the only currently implemented smart contract VM.

Introduction

Embedding transactions in blockchains incur fees, directly or indirectly. These fees exist as incentives to node operators, but are also essential to avoid the blockchain to be congested due to denial-of-service (DoS) attacks where huge amounts of spam are added to the blockchain for free.

In order to ensure that fees are paid, most blockchains support a specific, or a select few signature algorithms. Using a cryptographic signature, the payer of a transaction "signs off" on the fees. For example, Bitcoin and Ethereum support the ECDSA signature algorithm through the secp256k1 curve. Bitcoin also supports Schnorr, while Ethereum supports BLS for validator signatures.

No other signature algorithms can be used.

Built-in spam protection

Coinweb uses the Inchain architecture which means that the inputs to Coinweb are already in a blockchain. When transactions are processed by Coinweb, they have already paid a fee to be included in the underlying blockchain. This means that Coinweb has a built-in spam protection mechanism by leveraging the spam protection of the underlying blockchains.

Free gas allowance

Coinweb takes advantage of this by executing transactions directly without asking for up-front fees to be paid. Instead, Coinweb transactions that start their execution directly from an underlying blockchain get a small gas allowance from the Coinweb network for free.

This gas allowance is enough for the transaction to invoke a user defined signature checking smart contract (user contract).

When the user contract succeeds in checking the signature of the transaction, this smart contract will unlock CWEB owned by the user similar to how signature checking in Bitcoin unlocks UTXOs or how signature checking in Ethereum unlocks access to the ETH stored in a given account.

note

Coinweb tokens also supports gas fee abstraction which is a higher level concept supported by tokens issued by the tokenization platform.

User contracts have custody of CWEB

Each user contract acts as a custodial smart contract for CWEB, protected by the particular user contract.

There might be one user contract for ECDSA/secp256k1, and another designed for DAOs that uses Schnorr. User contracts ensuring quantum resistance can be added.

An EVM compatible user contract exists so the Coinweb network can be used from EVM compatible wallets such as Metamask.

Claims are used to store the CWEB that the user contract has custody over. Typically a transaction will invoke a user contract and ask for one or more claims to be spent, similar to how a Bitcoin transaction refers to one or more UTXOs to spend in a transaction.

After checking that the claims are owned by the signer, the user contract will then construct a new transaction that TakeOp the specified claims, spending the CWEB into the transaction, as well as invoking a target smart contract specified in the original transaction.

After passing through the user contract, the next smart contract invoked will end up with the spent CWEB and can use it for further processing, such as sending it off to another User.

The user contract supports two methods related to it having custody of CWEB. Those are the fund and the send methods.

• fund asks the user contract to fund a provided transaction with a certain amount of CWEB
• send asks the user contract to store a certain amount of CWEB for a given User.

User contracts define a User

Since Coinweb can have a multitude of user contracts, how do smart contracts keep track of who owns what? In Ethereum, this is managed using an address. In Coinweb, smart contracts use a User.

A User in Coinweb is simply the combination of a user contract's identity (32 bytes), and some auxiliary data that the user contract requires to identify the user.

As a convention for user contracts, in the transaction that it creates (the one that typically contains one or more TakeOps and a CallOp), it also effectively passes along a User argument to the next smart contract.

As a technicality, it passes along only the auxiliary data, for example the public key in case of an ECDSA user contract. This is passed as a verified DataOp which is just data, but not forgeable and issued by a particular smart contract. The (unforgeable) issuer of the DataOp together with its contents is the User.

Smart contracts that index data based on User will work with any user contract.