4.6. Programmable Accounts
For specific use cases, Sequentia allows users to switch from the UTXO environment to an account-based one through its programmable accounts. 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, for example, when it is required to frequently move small amounts (“dust”) that would not be consolidated.
To create and access programmable accounts, a set of new OP_CODES expanding the Bitcoin script system is introduced in Sequentia. 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 allow Turing complete smart contracts (17).
When new blocks are generated, in addition to making regular checks on transaction scripts, block creators 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; in order to send funds to another contract or address, a contract needs to spend the output through a transaction in the Account Transactions List, that is generated by block creators 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 creator 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
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 creators to get rewards for performing calculations based on the actual workload of the smart contracts. A block creator 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. Normally the address of the sender of the transaction with the special OP_CODE pays the gas, but OP_SENDER allows any address, such as a third-party service provider, to pay for commissions. Potentially, any RAS token can be used to pay 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 tiny space dedicated in each block 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, while 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 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 on. Addresses of programmable accounts have a different format than 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 creator 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;
In other cases, a specific percentage of the amount transferred to be used as a 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
Last updated