4.6. Programmable Accounts

Sequentia's programmable accounts allow users to switch from the UTXO environment to an account-based one for some specific use cases. These Accounts allow Sequentia users to create DAOs or other smart contracts that are otherwise unfeasible in a UTXO environment. Also, there are occasions when script-based transactions can cause more network pollution, such as when it is required to move small amounts (“dust”) frequently that would not be consolidated.

Sequentia introduces a set of new OP_CODES expanding the Bitcoin script system to create and access programmable accounts. Every node will parse the script in Sequentia UTXO transactions and process all those with said special OP_CODES differently to run in a virtual machine and also enable Turing-complete smart contracts (17).

When new blocks are generated, in addition to making regular checks on transaction scripts, block producers also need to check whether transactions contain the special OP_CODES: when parsing the set of input of a UTXO transaction (vin), the validator checks if the outputs exist and are unspent, then checks if vin is spent through one of the special OP_CODEs. If that is the case, the vin of a UTXO is passed to the Virtual Machine. If more UTXO exist for the same contract address, a transaction is created, condensing them into a single output.

Contrary to UTXO, programmable accounts have a state; to send funds to another contract or address, a contract needs to spend the output through a transaction in the Account Transactions List, which is generated by block producers while verifying and executing the special OP_CODES, rather than being generated by the users. As such, these Account Transactions are not broadcasted on the P2P network.

When the Account Transactions List is processed, the smart contract script is part of the input (vin), while the output (vout) only provides the pubkeyhash, an optional change address or another contract’s address. This way, outputs always remain constant in size.

OP_DEPLOY is the OP_CODE deploying a new contract to the blockchain, with an output script that includes the smart contract code and information regarding the gas:

• VM version number (in case of more than one, anticipating future upgrades)

• Gas limit (maximum amount of gas that this execution can use)

• Gas amount (how much unit of the token used as gas to be used)

• Gas token address (which token is used as gas) Contract bytecode

A programmable account ruleset can be configured to establish a contract owner who can update or destroy the programmable account. The accounts can be cleared with a transaction by creating a new UTXO of the same amount of tokens in the account-based balance (minus the fee paid to the block producer for that transaction).

OP_ASSIGN sends UTXO funds to an existing smart contract, identified with its transaction id hash

inputs:

• VM version number

• Gas limit

• Gas amount

• Gas token address

• The hash of the transaction ID of the smart contract

• Additional data to be sent to the contract (how tokens interact with the contract, e.g., ABI in Solidity)

outputs:

• Spendable: if vin returns 1, that means funds are spendable according to the contract logic, and the transaction is therefore placed in the Account Contracts List

Programmable accounts implement the concept of “gas” and allow block producers to get rewards for performing calculations based on the actual workload of the smart contracts. A block producer runs the script and checks if there is enough gas. If yes, funds are assigned to the contract; otherwise, the transaction is invalid and reverted to the previous state. Usually, the address of the transaction sender with the special OP_CODE pays the gas, but OP_SENDER allows any address, such as a third-party service provider, to pay for fees. Potentially, any RAS token can be used to pay these gas fees.

Transactions in programmable accounts have a completely separate fee market because only a small part of the block space is dedicated to these transactions. A limited amount of dedicated blockspace discourages using programmable accounts for automated market-making DEXs, which are not scalable and would end up clogging the blockchain. Instead, the focus for high-frequency DEX transactions on Sequentia should be off-chain, as detailed in §5.2, whilst programmable accounts could be used for DAOs, special ACL rulesets, or other use cases where they would be more efficient than a UTXO in terms of dust generation.

Users transferring UTXO with a Bitcoin script will never incur the risks of a Turing-complete environment because these smart contracts will never affect their assets unless they deliberately send tokens to a programmable account or create an account-based address to receive tokens. Addresses of programmable accounts have a format different from UTXO addresses.

Some tokens can be created with ACL rules requiring that each transaction passes through a programmable account. To do that, the output of the ACL must have a single whitelisted programmable account address so that every transaction using that token/ACL is parsed there. In that case, the transaction will necessarily execute the programmable account’s ruleset to be validated, which may enforce sending a fee to a specific address (e.g., taxation) or all the addresses holding a certain amount of tokens (e.g., dividends). The amounts paid may increase the balance of an account-based contract rather than a UTXO.

Two possible use cases are sketched below:

1. Dividends: an address can receive a share of the funds held in an indicated reserve, depending on how many tokens it stores (e.g., security tokens representing quotas of the shareholders). The creator of the programmable account defines:

• Specific address(es) entitled to receive the funds;

• A defined share of funds the beneficiary needs to hold (even in the UTXO system), which is required to be eligible as a beneficiary of the dividends;

• The reserve address(es) from where dividends are paid;

• The combination with any ACL filter.

2. Taxation: an indicated address can receive taxes for each transaction made with a specific token. The creator of the programmable account defines:

• The address that collects the taxes;

• A fixed quantity of tokens to be paid as tax for each transaction;

• Alternatively, the specific percentage of each transaction that will be collected as tax.

Footnotes/p4.6

17. The process is inspired by Qtum: P. Dai, n. Mahi et al., Smart-Contract Value-Transfer Protocols on a Distributed Mobile Application Platform, Qtum Foundation, Singapore, 2016