Sequentia is a Bitcoin sidechain network and corresponding ecosystem of applications dedicated to tokenized assets – like stablecoins and stock tokens – and peer-to-peer transactions, including direct, real-time atomic swaps and lightning swaps between BTC and tokens issued on Sequentia.

The Sequentia Network's initial development and launch are being promoted by Concatena Labs, Inc., a Delaware corporation. However, Sequentia is a fully Free and Open Source (FOSS) project and anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

Testnet documentation

Instructions on how to run Sequentia's modified Elements node in order to connect to the public Sequentia testnet network, as well as a few commands to demo the "No Coin" feature. This feature is our proof-of-concept, and it is what makes Sequentia the first blockchain in history without a native coin, as well as the only pegless Bitcoin sidechain.

Light paper

General information about the protocol can be found in the Sequentia Light paper. Download the pdf version here.

Theoretical paper

This academic-style paper provides detailed information about the protocol, the consensus system, and how it differs from other asset tokenization technologies. The PDF version is available here.

White paper

More information about the Sequentia protocol and its role within the Bitcoin ecosystem can be found in the Sequentia White Paper. You can download the pdf version here or follow the link to read it online:

Join on socials to learn more

You can join us on Discord here or via Telegram below:

• To create a wallet, use the following command and change <YOURWALLETNAME> with the desired name of your wallet (without the symbols < and >).

.\elements-cli -named createwallet wallet_name=<YOURWALLETNAME> descriptors=false load_on_startup=true

• Then generate an address using the following command. The output will be a long string of letters and numbers like “el1qqg3yq85yuzrlukqsw7tm8…….”. Copy and save it somewhere so you can send it to other people to receive tokens:

.\elements-cli getnewaddress

• To get a “confidential address” to share with other people to receive confidential payments, run the following command substituting <generatedaddress> with the value you obtained using getnewaddress in the previous step. You will find a new address string under “confidential” among the extensive info in the output.

.\elements-cli getaddressinfo <GENERATEDADDRESS>

• As per the settings we added to the configuration file, for testing purposes only, we have a block subsidy of 1 TEST per block. The block subsidy unlocks after 100 blocks, so to get a balance of 100 TEST, we need to create 200 new blocks with the following command. Replace <GENERATEDADDRESS> with the address string obtained in the steps above

.\elements-cli generatetoaddress 200 <GENERATEDADDRESS>

With this command, you will mine a block and receive the block reward (which consists of the corresponding transaction fees plus the block reward since the given testnet configurations have a block subsidy for the purpose of this demo).

The command generatetoaddress <nblocks> <address> mines blocks to a specified address, with the following arguments:

1. nblocks (numeric, required) How many blocks are to be immediately generated.

2. address (string, required) The address to send the newly generated TEST to.

The output will be a string like this that represents the blockhash:

587f9c4fc679c63b98650330f34ea57adbe872d05c69589a52c9ace1d5c860f2

If you run .\elements-cli.exe getblockchaininfo again you will find the same hash under the field “bestblockhash" (as long as that block is the tip of the chain, i.e. the last valid block produced in the network)

We finally have a wallet with a spendable balance in “TEST”, and we can now test the functionality of our chain.

This Sequentia testnet and demo walkthrough showcase Sequentia’s “No Coin” feature: the first free market for transaction fees in the history of blockchain technology. Sequentia's codebase is being built as a fork of the Elements Project, which is itself a fork of Bitcoin's codebase and is currently best known for its implementation in the Liquid Network, which is also a Bitcoin sidechain.

However, unlike in all other Bitcoin sidechain networks (and, in fact, unlike in every other blockchain network to date), any asset issued on the Sequentia Network can tentatively be proposed to pay transaction fees on the network. This demo is presented as a proof-of-concept for the ability to create, send, and receive tokenized assets on Sequentia, with transaction fees paid using any Sequentia asset of your choice. Specifically, the walkthrough will show you how to use the following features:

• Issuing an asset and then transferring this asset using the same asset to pay for transaction fees.

• Transferring an asset using a different asset to pay for transaction fees.

• Broadcasting a transaction that transfers an asset using a different asset to pay for transaction fees, but setting a fee that is too low, then using “Replace-By-Fee” on such a transaction that remains unconfirmed, bumping the fee using the same fee asset, or even replacing the fee asset with a different fee asset (e.g. proposing a transaction with the fee paid in USDT, then using RBF to instead propose the transaction fee in USDC).

The role of the “price server” in the Sequentia Network

To enable block producers to decide if and when to include a transaction in a block based on the value of the fee paid, in order to create blocks which have the highest possible fee value despite fees being proposed in a variety of assets, we have developed a “price server” software and several mechanisms which nodes enforce to evaluate and compare fees. Node operators are free to decide if and when to connect to a price server in order to retrieve prices, or they can alternatively just set prices manually in their node configuration (this is what we will do in this walkthrough), which is reasonable if they are only interested in transactions that pay fees in one or a few known assets, such as for example a reputable, stable asset like USDT or USDC, and ignore any other transaction.

Multiple price servers could run simultaneously alongside the Sequentia Network since any user can run such software. We envision that price servers will likely be maintained mainly by power users such as traders, market aggregators like Coinmarketcap, exchanges, oracles, or trading-related services. In the first version of the Sequentia Network mainnet, members of the strong federation that will produce blocks will also maintain their own price server(s).

This innovative free market for transaction fees will introduce interesting new dynamics and opportunities. Average (a.k.a. "retail") users will benefit most directly from this feature because of its benefits to user experience and network scalability, given that most transactions will have their fees paid using the same asset that the user intends to transfer over the network. There will, therefore, no longer be a need for transactions with the sole purpose of acquiring a specific token that has no other utility to the user other than being required for transaction fees. Such a system can also bring better balance and price discovery to tokenized asset markets, measured in terms of asset liquidity, volatility, and adoption brought about by a better evaluation of how much any asset is worth against any other asset in the market.

Differences between current testnet, future testnet, and mainnet

This demo showcases the free market for transaction fees (also referred to as the “No Coin” feature) using a testnet configuration, which, for testing purposes, will have a few key differences from the upcoming Sequentia testnet and mainnet releases. The main differences are the following:

• Anyone can produce blocks

This allows testnet users to play around with and run tests on the node and wallet without being subject to standard block production dynamics, including block frequency, since anyone can mine their own transactions at any time. In other words, no consensus mechanisms prevent users from creating blocks and earning block rewards; any user can do that without restriction. By contrast, in the first mainnet release, there will be a “strong federation” of blocksigners, similar to that of the Liquid Network, that will produce blocks (at a frequency and maximum blocksize that will also be similar to that of Liquid), while in a future mainnet consensus upgrade, this federation will be opened to the market by allowing anyone to join it through a staking mechanism.

• Block subsidy

In this demo and in the public testnet network generally, every block generates a coinbase transaction which distributes a block subsidy denominated in a token, which we will refer to as “TEST”. In the future Sequentia testnet and mainnet, there shall be no block subsidy of any kind, and there will, in fact, be no native "coin" whatsoever on the Sequentia Network. The only purpose of TEST is to allow you to test the network promptly, i.e. without getting test tokens from a faucet or from other community members. You will get a coinbase reward of 1.0 TEST when mining blocks, and this reward will be unlocked after a subsequent 100 blocks have been mined.

Note that the Sequentia testnet will also have an initial asset issued which will be called “USDT” and will simulate the first stablecoin issued on Sequentia. However, in the testnet, regular users will not be able to generate TESTUSDT themselves, either through a block subsidy or otherwise. Instead, they will have to use testnet faucet services or ask other community members to send them testnet tokens in order to get started. This is because the behaviour of the testnet should reflect the behaviour of the mainnet as closely as possible, and indeed, only Tether, Inc. is supposed to issue USDT (and, in any case, not via block subsidy, but with the issueasset command).

• Future development

The testnet does not yet feature the next most important milestone in Sequentia’s development: Bitcoin Anchoring. In a nutshell, Bitcoin anchoring is a consensus rule which requires Sequentia blocks to have a reference to Bitcoin blocks, such that both chains always reorganize together and cross-chain operations such as atomic swaps can happen in real-time (instead of being subject to lengthy timelocks) as a result of this reorg-protection. This feature will be developed in the next phase of Sequentia's development, together with a front-end interface (wallet) for multiple devices and the first Bitcoin-Sequentia DEX, enabling p2p swaps between assets issued on the Sequentia Network and BTC on the mainchain or the Lightning Network. Combined with the free market for transaction fees, these make up the "minimum viable product" required for launching the Sequentia mainnet. Sometime after the network's initial launch, we will propose a hard fork to the Sequentia Network to open up the federation of block producers to market-based participation.

Join the community!

Join our public Discord server to interact with the Sequentia community, developers, and contributors. You will find support if you have questions or are stuck on your tests. Also, if you find any vulnerabilities in the system, please report your findings so we can fix them!

Now, let’s get started!

To ensure that all commands in the walkthrough of the "No Coin" demo work correctly, you must follow these walkthrough instructions in the following order:

Download

https://github.com/SequentiaSEQ/sequentia/releases/tag/testnet-v0.2

Installation

In order to connect to the current public testnet, you can keep the provided elements.conf file in the archive linked above or create your own using the parameters at https://testnet.sequentia.io/

To create your own configuration file, if you are a Windows user, create a simple text document (using your favourite editor, such as Window’s default “notepad” application) and simply copy and paste the desired configuration parameters inside it. Then, rename the file to elements.conf, making sure that .conf is the extension. If you are not able to edit the extensions of Windows files, follow these steps.

Then proceed as follows.

For Linux:

• Extract archive

• create .elements dir in your root directory

• move elements.conf to ~/.elements/

• run elementsd in sequentia-testnet-linux

• use elements-cli to execute some RPCs

For Windows:

• Extract the archive you downloaded to any Windows folder

• Create the “Elements” directory in C:\Users\<username>\AppData\Roaming\ The fastest way to reach that directory is to click on windows key + R, type %appdata% and click “OK”. When you browse to c:\Users\<username> if you don’t see the folder AppData, select folder options → view → “show hidden files, folders and drives”.

• Move elements.conf to the new directory C:\Users\<username>\AppData\Roaming\Elements\

• Run the file elementsd.exe in sequentia-testnet-win by double clicking on it (or using the "command prompt” app with the command “cd <path to the directory with the file>)

• If Windows’ User Account Control prompts you to allow changes to be made to your device, click ‘Yes’

• If Microsoft Defender SmartScreen prevents an app from running, click “more info” and “run anyway”.

• If Windows Defender Firewall or Windows Security prompts you to allow access on your network, select the appropriate options and click “Allow access” or “Allow”.

For macOS:

• Coming soon

The rest of this demo walkthrough will only provide command and output syntax based on Windows, but where needed or relevant, it should be fairly straightforward to adapt to any other operating system.

Always leave the application elementsd.exe open whenever you use the node, wallet, RPCs, etc. To keep it running in the background, change the line in elements.conf file to daemon = 1 rather than daemon = 0.

Now open the Windows application "Command prompt". Use the “cd” command within the command line to access the folder “bin” in the folder where you extracted and saved the sequentia-testnet-win archive. Inside that folder, you will find the file elements-cli.exe that you will use to execute commands on your node.

For example, on my personal Windows machine, I would type this and then press enter:

cd C:\Users\alber\Desktop\Sequentia Testnet\bin

Use elements-cli.exe to execute some RPCs (.\elements-cli.exe). For example, use the following command to scan the blockchain. In the output, you will see the number of blocks under "blocks" and the size of the blockchain, among several other bits of information.

.\elements-cli.exe getblockchaininfo

You are now ready to go!

Now let’s generate a second address and try sending TEST for the first time. The transaction fee will be subtracted from the amount, therefore you will pay the fee in TEST directly

With the following commands, we first generate a new address (let’s refer to it as GENERATED_ADDRESS_2) and then we send 50.0 TEST to this address. We can then check our history of received assets using the getreceivedbyaddress command.

.\elements-cli getnewaddress

.\elements-cli -named sendtoaddress address=<GENERATED_ADDRESS_2> amount=50.0 subtractfeefromamount=true

Although the transaction is correct, if you check the balance of the new address now, it will still be zero. That is because your transaction still needs to be confirmed in a block. So, create a new Sequentia block by using the command:

.\elements-cli generatetoaddress 1 <GENERATED_ADDRESS>

1. Now check that the 50 TEST have been sent to the new address

.\elements-cli getreceivedbyaddress <GENERATED_ADDRESS_2>

If everything is correct, your command prompt will look similar to this:

.\elements-cli getreceivedbyaddress ert1qspt937gpfmeghshpaucar2d94g4hftq4m5zfg4
{
"TEST": 49.99999645
}

Showing that the fee has been paid in TEST and has been subtracted from the amount sent (50.0)

3.1 Issue the asset

To create a new asset, use the command issueasset. Like regular Sequentia transactions, this command can also use any asset to pay for transaction fees. The arguments of the function are the following:

• assetamount (numeric or string, required) Amount of asset to generate. Note that the amount is BTC-like, with 8 decimal places.

• tokenamount (numeric or string, required) Amount of reissuance tokens to generate. Note that the amount is BTC-like, with 8 decimal places. These will allow you to reissue the asset using the `reissueasset` command as long as at least one satoshi unit (0.00000001) of the reissuance token is in your wallet. These tokens are not consumed during reissuance.

• blind (boolean, optional, default=true) Whether to blind the issuances for confidential transactions.

• contract_hash (string, optional, default="0000...0000") Contract hash that is put into issuance definition. Must be 32 bytes worth in hex string form. This will affect the asset id.

For this test, we will use only the first two arguments.

The output of issueasset will be similar to the following by way of example. You have to take note of the assetid under “asset”, that is, the HEX ID of your asset:

Create a block to confirm the transaction:

3.2 Give a name to the asset

Now let’s give a name to this asset. We have to stop and re-run the application:

Then execute elements daemon (elementsd) with parameter assetdir associating the HEX ID of the asset you issued. Replace <MY_ASSET_HEX_ID> below with the label you want to assign to it (the label is not written onchain, it’s part of your local node configuration). Imagine we are Tether Inc, and we are issuing USDT:

At this point on Windows you might need to re-open the command prompt.

Alternatively, rather than running .\elements-cli stop and changing the label via RPC, just close the application running your node, open elements.conf file and write at the bottom:

For example:

For more asset labels, just add new lines below with assetdir=<YOUR_ASSET_ID>:<YOUR_LABEL>

You will be able to use these labels instead of the assetid in the commands you will execute next.

Then re-run elementsd.exe

Then, check if everything has been done properly. The following command will allow you to see all issued assets and their characteristics. The output should contain information such as the amount of each issued asset and other characteristics like the asset label that you have associated with it.

3.3 Set a price for the asset

Now we have to set a price for this asset, that is, an exchange rate compared to other assets. Otherwise, this asset will be considered of no value, and your own node will not broadcast a transaction that pays fees with such an asset!

For mainnet nodes, price data will generally be retrieved from a third-party server, but users can always set it manually in their node, as we are doing now.

You may need to replace USDT with another label if you named it differently. Alternatively, you can use the asset hex ID instead of a label. In the latter case, the command will look like this, for example:

Note that we are going to issue another asset which we will use later when replacing the asset used for fees in a transaction

This command created a new asset. Let’s call it ASSET_2, whereas the one we created before will be referred to ASSET_1. Then, I can set all the asset prices this way:

In this case, ASSET 2 is worth twice as much as ASSET 1, which in turn is also worth twice as much as TEST. Imagine that the smallest unit here is a price like 1 satoshi as a reference unit, then one unit of ASSET_2 is worth four hundred million (400.000.000) satoshis while TEST is worth only one hundred million satoshis (100.000.000). Obviously, the choice of satoshis as a reference unit here is completely arbitrary; the user is free to set whatever they want, whether dollars or cents or milliBitcoin (BTC) or anything else. The important thing is that the relative prices of the assets measured in that reference unit are correct. The price server will provide this information, while front-end interfaces such as wallets will have custom options to display it.

Remember to create a new block when you make transactions or issue assets:

Sequentia is a new blockchain network with its own wallets, block explorers, and services. It is an open-source project, and anyone is free to contribute to or fork the codebase, or create alternative software following the consensus/protocol RFC.

Specifically, Sequentia is a Bitcoin sidechain dedicated to asset tokenization – like stablecoins and stock tokens – and Decentralized Exchange transactions, including direct atomic swaps (§5.1) and lightning swaps (§5.2) between BTC and any token issued on the Sequentia sidechain.

Sequentia is defined as a sidechain by virtue of the anchoring mechanism (§3.4) between Sequentia blocks and Bitcoin blocks. This link to Bitcoin also affects the network’s technical architecture and the consensus system, resulting in a hybrid mechanism employing both Bitcoin’s Proof of Work (“PoW”) and some parts of the stake-based governance of a typical Proof of Stake (“PoS”) system.

Sequentia blocks are created by users who have a large enough stake in the network, in the form of Sequence (SEQ) tokens locked through a staking mechanism. However, unlike virtually all other PoS networks, there is no specific token to pay transaction fees with over Sequentia; any token can be accepted by block producers, in a free market of transaction fees (§3.2). This lack of a native fee token (also known as a “Coin”) reduces friction in user experience and improves scalability.

Anyone is free to create a different wallet and node. However, some specifications are recommended for developers building on Sequentia that are willing to stick to the fundamental principles illustrated in this White Paper.

Ideally, a Sequentia wallet should have multi-token support and the following basic multi-token functionalities:

• Store, send, and receive Bitcoin just like any other traditional Bitcoin wallet

• Store, send, and receive tokens issued on the network, known as RAS tokens (where RAS stands for Regular Assets on Sequentia §4.2), including Sequence (SEQ) tokens, the governance utility token of the Sequentia blockchain.

• Allow users to manually set on-chain fees, choosing the specific token to pay fees with and the amount. The possibility to query a service for the calculation of fees is recommended.

• Allow replace-by-fee and child-pays-for-parent functionalities; this is particularly necessary because acceptance of transactions by block producers is optional, and may depend on the token chosen by the user sending the transaction..

• Process the Access-Control-List rules (see §4.5), which are introduced for security/stock tokens or other tokens that require particular policies.

• Process Bitcoin script smart contracts.

In addition, it is preferable for Sequentia wallets to also allow users to:

• Batch transactions (see §4.4) with peers before broadcasting to the network, in order to pay lower fees, alleviate the burden on the blockchain and accelerate transactions.

• Use the Lightning Network for transactions (both with BTC and RAS tokens).

• Peer-to-peer exchange BTC and RAS tokens using an atomic swap DEX (see §5.1) and lightning swap DEX (see §5.2).

Ideally, a Sequentia full node offers all the wallet functionalities listed previously, plus the following:

• Stake SEQ tokens to become a participant in the network’s block production mechanism.

• When selected to do so through this mechanism, propose or countersign blocks and earn transaction fees.

• Create a RAS token by executing an on-chain transaction in Sequentia.

• Make updates to RAS token policies (such as ACL, see §4.5).

• Create custom smart contracts and programmable accounts (see §4.6) to manage financial operations.

• Connect to services to query for DEX data (such as the DHT order book, see §5.4). Standard wallet API may be provided so that oracles can be programmed to help build smart contracts on Sequentia using third-party information.

A Sequentia full node retrieves information regarding the Bitcoin blockchain from the Bitcoin network, ideally through a self-hosted Bitcoin Core full node.

Sequentia full nodes may also eventually implement utreexo (2), which compacts the size of the UTXO set down to 1 KB. As such, pruned nodes will never take up more than around 1.5 GB of space (about three days of blockchain at maximum throughput), even in the long run.

Footnotes/p2

2. https://dci.mit.edu/utreexo

There is only one blockchain that we consider perfectly adequate for monetary settlements, and that is Bitcoin. We are also convinced that Bitcoin payments already are (and will continue for the foreseeable future) successfully scaling through the adoption of “Layer 2” technologies, that is to say, off-chain payment networks that allow self-custody and unilateral exit with on-chain (“L1”) transactions, such as the Lightning Network. The idea behind Sequentia is to complement this “L1/L2 stack” with a sidechain designed for all other financial transactions.

Despite being the most decentralized, robust, and antifragile network ever created, we contend that the Bitcoin blockchain requires such a sidechain in order to reach its full potential of becoming the backbone for not just the hardest money but also the most accessible, free, and truly global financial markets in history.

The practice of representing assets or other rights with tokens on an existing blockchain, also known as “tokenization”, initially started on the Bitcoin blockchain using solutions that relied on committing data inside of Bitcoin UTXOs, and later drifted to other public blockchain networks due in part to scalability limitations on Bitcoin. As mentioned, the Lightning Network has largely solved the scalability problem for Bitcoin itself, and a future can therefore be envisioned where the opening and closing of Lightning channels in BTC will represent the majority of on-chain transactions in the Bitcoin blockchain. However, even in this scenario, blockspace is far too scarce and costly to also support a fully dynamic and adaptable tokenized financial market, even if most tokenized assets with higher liquidity are exchanged on Lightning.

The Lightning Network requires on-chain transactions for both initial channel creation and final settlement of payments through channel closure, and having more than a single token over the Bitcoin blockchain means that payment channels must be opened and closed for all the tokens involved, at least as “assets at the edges”(1). Since the predominant use-case of tokenization is the issuance of financial instruments, many tokenized assets (henceforth simply “tokens”) will therefore likely not have enough liquidity and adoption to be easily exchanged over Lightning in the foreseeable future, especially tokens representing, for example, shares and obligations of relatively small companies and entities. Even for tokens with higher liquidity, a well-connected network of payment channels might still take years to develop properly.

Meanwhile, the so-called “Decentralized Finance” (“DeFi”) phenomenon which precedes Sequentia’s inception emerged mainly outside of Bitcoin, on blockchains where running nodes is only feasible with specialized servers rather than average consumer devices. The design philosophy of these blockchains has failed to achieve anything in favor of network utility or scalability: their fees are skyrocketing regardless, while most of their users face high barriers to entry for running a node and are therefore left outside of blockchain governance decisions. Rollbacks and changes to consensus rules, for example, are discussed only within a tiny segment of users, primarily miners or the most influential public figures. These conditions pose security threats for average users that primarily rely on light nodes or custodians, and lead to more centralized project choices.

Not only does no existing blockchain present any credible long-term plan for on-chain scalability without making unacceptable compromises to full node proliferation, but just as importantly, no other cryptocurrency can match Bitcoin’s quality as money, and all existing blockchains other than Bitcoin either impose their own separate Coin or (in the case of many Bitcoin sidechains) use a Bitcoin derivative (or "bridge") with separate network effects to (i.e. frictions in interacting with) the L1/L2 stack. Moreover, built-in Turing-Completeness, a feature of all the most well-known DeFi solutions at this time including some existing Bitcoin sidechains, has historically caused users and investors to encounter unnecessary risks while interacting with smart contracts, which may result in much more unpredictability than Bitcoin script smart contracts.

Sequentia is therefore the first Bitcoin sidechain designed for reliable, direct, and frictionless interoperability with Bitcoin and its second layers such as the Lightning Network while also leveraging and inheriting its resilience from Bitcoin’s proof-of-work, combined with an open, inclusive and market-oriented consensus mechanism to govern the creation of new blocks, and a lightweight infrastructure favoring a wide distribution of the network.

Footnotes/p1

1. e.g., in Taro. Only when there is a channel in the token Z between A and B and another between B and C, then is it possible to rely on the Bitcoin Lightning Network infrastructure already in place (like a Bitcoin channel between B and C) so that A can send Z tokens to C. However, still, it requires that the token issued has two opened Lightning channels “at the edges” of the payment route.

We will now spend the new asset whilst paying transaction fees directly in this new asset.

Let’s send the asset we created to a new address (GENERATED_ADDRESS_3)

.\elements-cli getnewaddress

In the following commands, replace GENERATED_ADDRESS_3 and ASSET, submit the transactions and create a new block as shown below:

.\elements-cli -named sendtoaddress address=<GENERATED_ADDRESS_3> amount=100.0 assetlabel=<ASSET> subtractfeefromamount=true

Take note of the transaction ID (txid), which is the string that the interface will show you when you run the sendtoaddress command (if it’s executed correctly). This txid will also be used later for another test in the next section (Replace By Fee).

You can also transfer TEST while paying fees in the newly issued asset. To do so, use TEST as the assetlabel, set subtractfeefromamount=false and then add fee_asset_label=<ASSET> with the label or asset id of the newly issued asset. For example:

.\elements-cli -named sendtoaddress address=<ANY ADDRESS> amount=1 assetlabel=TEST subtractfeefromamount=false fee_asset_label=<ANY ASSET IN YOUR WALLET>

Then, create a block:

.\elements-cli generatetoaddress 1 <GENERATED_ADDRESS>

Since we set “subtractfeefromamount=true” the payment used the new asset that is transferred with the payment to also pay for transaction fees

.\elements-cli getreceivedbyaddress <GENERATED_ADDRESS_3>

If you sent 100 tokens in the Asset you issued to GENERATED_ADDRESS_3, given the fee paid subtracted from the amount, you will see an amount transferred of about 99.99999864.

We have now demonstrated how the node handles payments using two different assets, TEST and a new asset you issued, as transaction fees.

Let’s move forward with something even more interesting!

Now, we want to broadcast a transaction with fees paid in a new asset, then make a replace-by-fee (RBF) transaction to bump the fee amount using the same asset, and then try another RBF transaction, which will change the asset used to pay for transaction fees.

5.1 Create a Raw Transaction

In the previous section, we took note of the TXID of the last transaction we made. We will use the output of such a transaction as our input for a new transaction. However, if you want to use another UTXO with different vout(s), you may want to check all UTXO you can spend so that you can retrieve the transaction IDs (TXID) of all unspent assets - you can do this with .\elements-cli listunspent. This will allow you to manually collect all the information you need to create a rawtransaction.

If you want to send the transaction to a new address, run this command again:

.\elements-cli getnewaddress

This will generate what we will now call GENERATED_ADDRESS_4.

Let's also generate an address where you can receive the change:

.\elements-cli getrawchangeaddress

We can call this latest new address "CHANGE_ADDRESS".

You are now ready to create a transaction that will be replaced by another transaction with a different asset with Replace By Fee. In the command below, replace TXID_ASSET_UNSPENT with the TXID of the transaction you made above, replace VOUT_NUMBER with 1 (since we will use only that single UTXO as input of this transaction), and replace GENERATED_ADDRESS_4 with the address of the recipient of this transaction you are preparing.

Now replace AMOUNT_TO_BE_SENT and CHANGE_ADDRESS in a way that their sum plus the "fee\":0.0001 in the token ASSET is equal to the input.

For example, if the UTXO you use as input has 100.0 USDT and you use USDT to pay the fees as well, you can set AMOUNT_TO_BE_SENT = 9.999, leave the fee at 0.0001, and set REST_AMOUNT = 90.0.

Replace the CHANGE_ADDRESS with the one created with the command above. Put any amount in REST_AMOUNT (e.g. 25.0) provided that it is less than the total output of the previous transaction (the TXID_ASSET_UNSPENT). Finally, replace ASSET with the assetlabel USDT (or whichever assetlabel you set during the asset creation step for ASSET_1) or its assetid. This will create a transaction that transfers ASSET_1 and also pays transaction fees in ASSET_1.

.\elements-cli createrawtransaction "[{\"sequence\": 4294967293,\"txid\":\"<TXID_ASSET_UNSPENT>\",\"vout\":<VOUT_NUMBER>}]" "[{\"<GENERATED_ADDRESS_4>\":<AMOUNT_TO_BE_SENT>, \"asset\":\"<ASSET>\"},{\"fee\":0.0001,\"fee_asset\":\"<ASSET>\"}, {\"<CHANGE_ADDRESS>\":<REST_AMOUNT>,\"asset\":\"<ASSET>\"}]"

Note that nSequence in Bitcoin, Elements and Sequentia signals if a transaction is replaceable or not:

• 4294967295 is Non-replaceable

• 4294967293 is Replaceable, see BIP-125

If you run listunspent command, the output will show a series of UTXO like the one below (for illustration purposes). If you want to find the one corresponding to the transaction you made in the last section of this guide, copy and paste the output from the command prompt window to a notepad or other text editor and search for the TXID that you took note of:

{
"txid": "da837fbd39ca134e64d31b6ccf98ac791cd9321d821410dcb5b35fa27c17e718",
"vout": 1,
"address": "ert1qagjq9puh6qh360f6xn2tu6dfxdw9qaj2e0mnem",
"label": "",
"scriptPubKey": "0014ea24028797d02f1d3d3a34d4be69a9335c50764a",
"amount": 50.99999854,
"asset": "8e577a160467091d755a64276326076f04c807884acf17b294e8df18cc0f89b5",
"amountblinder": "0000000000000000000000000000000000000000000000000000000000000000",
"assetblinder": "0000000000000000000000000000000000000000000000000000000000000000",
"confirmations": 1,
"spendable": true,
"solvable": true,
"desc": "wpkh([a6dcb78c/0'/0'/5']02cb3ff840320e978957a0d651d47b1385fdb15ffc911d0ecc50fbc467ef22fe2f)#7l8p3pdy",
"safe": true
}

Based on the above example UTXO, our createrawtrasaction command could look like this:

.\elements-cli createrawtransaction "[{\"sequence\": 4294967293,\"txid\":\"da837fbd39ca134e64d31b6ccf98ac791cd9321d821410dcb5b35fa27c17e718\",\"vout\":1}]" "[{\"ert1qagjq9puh6qh360f6xn2tu6dfxdw9qaj2e0mnem\":25.99989854, \"asset\":\"8e577a160467091d755a64276326076f04c807884acf17b294e8df18cc0f89b5\"},{\"fee\":0.0001,\"fee_asset\":\"8e577a160467091d755a64276326076f04c807884acf17b294e8df18cc0f89b5\"}, {\"ert1q3ye4hhrehsw0f99pprls7ljdwtjfv3wh07yy7z\":25.0,\"asset\":\"8e577a160467091d755a64276326076f04c807884acf17b294e8df18cc0f89b5\"}]"

Note that I am using 50.99999854 as input, which is exactly = 25.99989854 + 0.0001 + 25.0, i.e. the output: amount + fee + change.

The transaction that I am preparing sends the entire sum I just sent in the previous transaction to the new address I created, except for 25.0 tokens that will be “left” in the change address. Running the createrawtransaction command I will get a hex-encoded transaction, that is, a string that appears like this:

02000000000118e7177ca25fb3b5dc1014821d32d91c79ac98cf6c1bd3644e13ca39bd7f83da0100000000fdffffff0301b5890fcc18dfe894b217cf4a8807c8046f07266327645a751d096704167a578e010000000005f5e10000160014ea24028797d02f1d3d3a34d4be69a9335c50764a01b5890fcc18dfe894b217cf4a8807c8046f07266327645a751d096704167a578e01000000009502f9000016001489335bdc79bc1cf494a108ff0f7e4d72e49645d701b5890fcc18dfe894b217cf4a8807c8046f07266327645a751d096704167a578e010000000000002710000000000000

This string is the transaction hex id (TX_HEX_ID)

Now I want to sign this transaction:

.\elements-cli signrawtransactionwithwallet <TX_HEX_ID>

The expected output will be

{
"hex": "...688 digits....",
"complete": true
}

Let’s call the “hex” value the <SIGNED_TRANSACTION_HEX>, which you are going to use below.

We now want to broadcast this transaction to all peers. After running the command below, the transaction should be in your node's mempool:

.\elements-cli sendrawtransaction <SIGNED_TRANSACTION_HEX>

Note:

• If you get the error “bad-txns-in-ne-out, value in != value out”, then check that the value vout is exactly what appears in the UTXO of the txid you want to use (run the command .\elements-cli listunspent and check).

• If you get the error “Fee exceeds maximum configured by user (e.g. -maxtxfee, maxfeerate)”, then lower the fee.

• If you get the error “non-mandatory-script-verify-flag (Witness program hash mismatch)” probably you used the TX_HEX_ID rather than the <SIGNED_TRANSACTION_HEX>

If everything went right, you will instead get as a result a string like the following which is the TXID (transaction ID):

61185a96751065556ed8cd152a9adf13609a5007de355c4aae532f2c363dc129

Now, let's run the following command to check if the transaction is indeed in the mempool:

.\elements-cli getrawmempool true

The output will be something like this with the ID of the signed transaction and all its details:

.\elements-cli getrawmempool true
{
"61185a96751065556ed8cd152a9adf13609a5007de355c4aae532f2c363dc129": {
"vsize": 257,
"weight": 1028,
"time": 1718066562,
"height": 203,
"descendantcount": 1,
"descendantsize": 257,
"ancestorcount": 1,
"ancestorsize": 257,
"wtxid": "27daae8753487b9e103c0a53f79836aba426afeee037b9f9e6f7bac482b4a8e0",
"fees": {
"base": 0.00010000,
"modified": 0.00010000,
"ancestor": 0.00010000,
"descendant": 0.00010000,
"asset": "8e577a160467091d755a64276326076f04c807884acf17b294e8df18cc0f89b5",
"value": 0.00010000
},
"depends": [
],
"spentby": [
],
"bip125-replaceable": true,
"unbroadcast": true
}
}

5.2 Bump fee using the same asset

Now, let’s use RBF to bump the fee using the same asset (replace ASSET with the asset ID you used to create the rawtransaction. Replace TXID with the 64-digit transaction ID you got during the steps above. For the moment, in place of <ASSET>, insert the asset ID of the coin we are transferring, later we will also try changing the asset

.\elements-cli bumpfee <TXID> "{\"fee_asset\":\"<ASSET>\"}"

As output, you will see the transaction, the original fee and the new fee:

"txid": "6bfe018a5961ea247e53b66329b8f42a6759ee4748fb547defc339bad04ccf6b",
"origfee": 0.00010000,
"fee": 0.00011286,
"fee_asset": "8e577a160467091d755a64276326076f04c807884acf17b294e8df18cc0f89b5",
"errors": [
]

Check if the transaction has been updated in the mempool:

.\elements-cli getrawmempool true

You will see only the new transaction that has replaced the old one.

5.3 Replace-By-Fee using a different asset

Finally, we will perform a replace-by-fee transaction that does not just bump the fee to a higher value but instead replaces the fee asset with a completely different asset altogether!

Now use bumpfee to create an RBF transaction. We need to replace the last TXID

.\elements-cli bumpfee <TXID> "{\"fee_asset\":\"<ASSET_2>\"}"

Then check again the transaction in the mempool

.\elements-cli getrawmempool true

Finally, create a block with the replaced transaction using:

.\elements-cli generatetoaddress 1 <GENERATED_ADDRESS>

Check that the RBF transaction has been received and confirmed in the blockchain:

.\elements-cli getreceivedbyaddress <GENERATED_ADDRESS_2>

Finally, check your balance

.\elements-cli getbalance

Sequentia uses Bitcoin’s UTXO structure instead of an account-based model. From a certain point of view, the UTXO model is less efficient than the account-based model: since each transaction’s output is stored separately (even when sent to a single address), it is only possible to spend the entire transaction output. Therefore, most transactions must include change, creating what is commonly referred to as “dust” - smaller outputs that are costly to be transferred, given the fee’s weight relative to transaction volume. Despite this, the UTXO model has been chosen because of three essential features:

1. It is more privacy-oriented than other models because a single wallet usually utilizes multiple addresses, making it difficult and sometimes impossible to distinguish which ones belong to the same user. In contrast, account-based blockchains do not facilitate users’ privacy retention; for example, showing an address from a wallet may expose the users’ balance and the entire history of transactions not only in one token but in all tokens held by that wallet. With UTXO and Hierarchical Deterministic wallets (the most common Bitcoin wallets), it is instead possible to manage multiple addresses from the same wallet seed.

2. It is compatible with technologies already implemented in Bitcoin, such as HTLC-based smart contracts, including atomic swaps and the Lightning Network, that can be extended to allow swaps and DEXs. The combination of a UTXO system and Bitcoin script allows cross-chain interoperability with Bitcoin, while the addition of Anchoring (§3.4) makes this interoperability frictionless.)

3. Sequentia can inherit practices that were originally developed to improve privacy and scalability on Bitcoin, such as coinjoin and transaction batching with signature aggregation. Payments can be batched together (aggregated) in a single transaction, saving considerable space otherwise required for making a single transaction per payment. The practice of transaction batching is a particular focus in Sequentia’s value proposition. Aggregation can be made by a single service provider who transfers multiple transactions within a limited timeframe (e.g., the withdrawal requests of centralized exchange users), as well as through a peer-to-peer network among several independent users (3) (§4.4).

Script-based smart contracts are chosen over Turing-complete environments (e.g., EVM, WASM) which can process just about any rule set of data manipulation, resulting in infinite possibilities for developers to create smart contracts. Instead, Sequentia primarily relies on the Bitcoin-like script-based approach limited by a determined set of rules that must be followed. This approach sacrifices some versatility for higher safety, sustainability, and validation speed.

Generally, script-based smart contracts tend to produce less network pollution and execute faster than Turing-complete contracts, thus ensuring a more manageable environment for developers. As demonstrated by protocols that have taken the opposite approach, complicated architectures on blockchains may cause issues: having endless possibilities might end up clogging servers, while at its core, a Turing-complete system is not even required by most blockchain use cases since the majority of contracts do not even require a loop, and only a tiny percentage of smart contracts built on EVM truly require Turing-complete language functions (4). In order to prevent potentially infinite loops that require excessive resources, contract execution is generally limited by “gas” on EVM-based systems. However, transactions are nullified when a smart contract runs out of gas (the fee in gas is paid to the miner regardless). Therefore, it is necessary to provide enough gas in anticipation to cover the worst-case scenario, which is very difficult to foresee. It is one of the reasons why Turing complete smart contracts have shown a higher probability of breaking over time (5).

On the other hand, the flexibility provided by a script-based system is sufficient and proportionate to Sequentia’s basic DeFi and DEX functionalities without incurring the risks associated with Turing-completeness. Combining several simple scripts makes it possible to produce highly advanced contracts such as hashed timelock contracts (HTLC), whose potential and versatility are best exemplified by the Lightning Network. Two examples of very primitive script-based smart contracts are the multi-signature account and the timelock contract (6). Combining simple scripts like these makes it possible to create sophisticated contracts while keeping their basic components’ high reliability, efficiency, and predictability.

Footnotes/p3

3. This method is currently implemented with coinjoin in bitcoin wallets like Wasabi.

4. The following research says that only 6,9% of smart contracts built on the Ethereum Virtual Machine truly require Turing-complete language functions. It also notes that the vast majority of Ethereum’s smart contracts can be coded to function the same way on a Turing-incomplete machine. https://www.researchgate.net/publication/332072371_Do_Smart_Contract_Languages_Need_to_be_Turing_Complete

The Ethereum whitepaper (https://ethereum.org/en/whitepaper) reports that “Turing-incompleteness is not even that big of a limitation”. Out of all the contract examples that the Ethereum team had conceived when writing a whitepaper, only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code.

5. among historical failures, some of the more notable ones are the DAO hack and Parity’s multiple signature validation program.

6. Multi-signature requires a number n of signatures over m to unlock a specific unspent output, whereas time lock requires that the output is spent only after block x, or only n blocks after the event x occurred (event x might also be a particular transaction or block).

On the Sequentia network, users can pay transaction fees in any RAS (§4.2) token they choose as long as block producers are willing to accept it. Though "pegging" or "bridging" Bitcoin to the Sequentia Network is technically possible, Sequentia does not need a specific peg-in mechanism or any specific token at all to pay for transaction fees. Therefore, and in contrast with most other Bitcoin sidechains, Sequentia is not qualified as a “Bitcoin sidechain” due to the existence of a native Bitcoin derivative.

In other blockchains, the requirement for users to have a “gas bank” or reserve in a native cryptocurrency in order to transfer any other token creates barriers to entry and introduces frictions in user experience, preventing a broader network effect. In Sequentia, block proposers have incentives to accept any token as long as it has a recognized value and sufficient liquidity. They will retrieve and compare fee values by querying price data from CEX APIs or DEX oracles. If a transaction is taking too long to be included in a block or seems like it might never be included, the user may broadcast a new one with Replace-by-fee. To facilitate users’ choice, every block proposer may also signal the list of tokens that will be accepted according to a selection dictated by purely free-market logic. This freedom also improves scalability since there will be far fewer transactions made with the sole purpose of acquiring a coin only to be able to make other transactions, which ultimately implies higher transaction costs and pollution for the entire network.

Fees can tentatively be expressed in the token the user is transferring, or users can attempt to pay their transaction fees with any other RAS token among those available in their wallet. It is expected that most block proposers will accept all major RAS tokens, at least in terms of trading volume against BTC. Since the fee economy is a free market, block proposers have incentives to accept any token as long as it has a recognized value in the market and sufficient liquidity. Otherwise, transactions left behind might be grabbed by the next blocksigner. Simultaneously, the game theory for this mechanism may lead to the rejection of illiquid tokens, constituting an effective spam filter.

Network participants that need to calculate fee values (e.g., to choose which transactions are more valuable, in case the network is saturated) will query price data from a centralized exchange (using API) or DEX oracles. It is hypothetically possible for block producers to employ a client-side script to manage their staking node, wherein they could, for example: cross-check the trading volume of tokens chosen to pay for the fees of transactions currently in the mempool against BTC on a chosen CEX API or DEX oracle, build a block which will collect the highest possible value of tokens that can reliably be exchanged for BTC, and automatically atomic swap all of these tokens for BTC as soon as the block reward is spendable. Therefore, block producers could potentially receive a passive income composed solely of BTC to reward their SEQ stake, whilst simultaneously enabling users to pay transaction fees using a wide variety of assets, and facilitating these assets’ direct exchangability for BTC.

When preparing a transaction, a wallet’s UI may suggest a fee amount for each token based on an algorithm that analyzes Sequentia’s mempool and past transactions.

To secure cross-chain operations, Sequentia must minimize the possibility of chain reorganization or orphaned blocks due to dynamics intrinsic to the Sequentia protocol, that is, not depending on a chain reorganization occurring on Bitcoin. The model chosen for Sequentia to grant immediate finality involves having leaders and committees shuffled at each new round based on a seed derived from the block of the immediately preceding round. Each participant computes their own Verifiable Random Function (VRF) using this seed (public) as input plus a key (secret) associated with the tokens at stake. The result defines a committee and a leader per block.

After having calculated the VRF output, each blocksigner checks the VRF function of the block proposers, selects the lowest VRF output, downloads the corresponding block proposed, and checks if it is a valid block complying with the consensus rules (if not, it moves on to the second-lowest VRF function). When enough commitments from blocksigners are collected, they sign the block with their countersignatures. Once enough blocksigners approve a block, it is “certified” and has immediate finality. Requiring a minimum amount of countersignatures to validate a block is necessary, despite being a significant restriction, as it prevents leaders from hiding their VRF result, generating a parallel private chain that will be published later in an attempt to reorganize the honest chain.

The participants allowed to countersign a block in a particular slot are chosen through a randomized process to avoid exposing selected blocksigners to possible attacks. Also, relying on a subset of participants rather than the entire population helps avoid an inappropriately extensive and costly round-robin cosigning process requiring messages between blocksigners.

Thus, a subset of blocksigners called a “committee” is defined in each round to countersign blocks. The selection is random, but participants are weighted by their stakes. The seed of the previous round determines the blocksigners of the next round in a deterministic way. Every round, each participant runs the VRF using the last Sequentia block as a randomization seed, and when nodes discover a new Bitcoin block, participants are able to shuffle the leader set again.

Therefore, the process of block production and transaction finality can be summarized as follows:

1. Full node operators desiring to participate in the block production mechanism must put SEQ at stake and publish a verification key (VF) associated with a secret key (SK) controlling the SEQ at stake.

2. Assuming that a block is published at round r-1. A public seed is deterministically derived from this block.

3. Each participant runs the VRF function using the seed published in the block at r-1 (public) and their secret key SK (private) as input.

4. Given the output of the VRF function, a committee is determined. Each participant in the committee publishes their result to the network (including a new seed for round r) in a proposed block.

5. Nodes check the outputs of the functions other participants published, verifying that no one is cheating because it is possible to publicly verify that a valid SK is used, i.e. one associated with the VF published ahead of time (see step 1). The SK is not revealed when doing so.

6. It is necessary to single out just one block among all published. Therefore, nodes only propagate valid block proposals with the lowest VRF hash calculated at timeout (enforced locally with a timer each node runs and resets after receiving each new block) to the network.

7. If a participant knows about a new Bitcoin block (not referenced in the Sequentia block at round r-1), this participant can propose a block referencing the newest Bitcoin block and use its hash to reshuffle leaders.

8. To ensure that only one block is certified, a selection process is used in which every participating node votes for the block with the lowest hash of the VRF output.

9. After the timeout, if no block reaches the quorum, blocksigners vote again on the proposed blocks in round-robin cycles.

10. Blocksigners verify that the block complies with consensus rules (that is, that there is no double spending, overspending, etc.). The verification is made only after the first vote is done as to reduce the computational effort required to verify more than one block. If the block reaching the quorum is not compliant, the round-robin cycle restarts with the previous step.

11. When a block reaches enough votes (and if it is also otherwise valid), blocksigners aggregate all signatures to countersign it.

12. When the block reaches the minimum threshold of countersignatures and is certified, then it represents the block for round r, and a randomization seed from that block will be determined and used in the subsequent steps (starting again from step 3 above) for the next round (r+1)

Any blockchain network is exposed to grave security risks if the entities with the capacity to govern over block production do not have a significant interest in the network’s normal state of operation. The selection of entities with the power to issue blocks must be open to the market with publicly transparent economic incentives to participate. For example, in a Proof of Work system, miners have a considerable investment in the hardware and, in general, in their business model, from the most efficient way to supply energy to the vast amount of capital required for the set-up and maintenance of the business (including human capital, effort, aspirations). All of this capital represents a “stake” in the network.

Sequentia blocks are proposed based on a PoS selection algorithm that weights the stake of each participant (in terms of SEQ tokens at stake) to determine the right to issue a valid block. A PoS selection is chosen to avoid the security threats any new PoW intrinsically faces at its genesis, being at risk of malicious attackers borrowing hashrate power. However, to prevent the perception of being an alternative or competitor to Bitcoin, SEQ tokens are not intended to have a monetary purpose, as made evident by the open fee market described in the previous section.

Any network participant staking at least 0.01% of the total token supply has a chance to be selected by the algorithm as a blocksigner or block producer. 0.01% of the total token supply corresponds to 40,000 SEQ tokens. Participants with SEQ tokens locked at stake earn network transaction fees from the blocks they produce; therefore, the value of SEQ tokens mirrors the actual usage of the blockchain.

Each Sequentia block is anchored to a Bitcoin block for the sake of interoperability of smart contracts (e.g., hashed timelock contracts, also known as HTLC):

Any new Sequentia block includes a reference to the hash of a Bitcoin block. If Sequentia block X references Bitcoin block Y, the block X+1 necessarily references the hash of a Bitcoin block at a height equal or greater to Y. When a Bitcoin chain reorganization happens, Sequentia nodes discard all Sequentia blocks referencing the hashes of orphaned Bitcoin blocks.

Several Sequentia blocks can be built referencing the same Bitcoin blockhash, since the frequency of Sequentia block generation is higher than Bitcoin’s.

Anchoring enables faster and more reliable cross-chain operations between the Bitcoin and Sequentia networks. Any operation involving two different chains (that are not synchronised by a consensus rule such as the one described here), like an atomic swap for example, requires waiting for long confirmation times (several blocks on both blockchains involved) to ensure that the operation will not be reverted in one of the two networks. With anchoring, if the Bitcoin network reorganizes or orphans one or more blocks, the Sequentia network also reorganizes or discards accordingly all Sequentia blocks that reference the Bitcoin blocks that have changed height or been orphaned. Therefore, if a cross-chain operation involving Sequentia is removed from Bitcoin’s block history (e.g., an atomic swap), the corresponding operation on Sequentia is also removed from Sequentia's block history.

It is important to note that anchoring does not allow for more reliable cross-chain transactions without other assumptions detailed in the following sections: persistence §3.5, consistency §3.7. The anchoring mechanism is also utilized for purposes relating to the properties of liveness and security of the blockchain (escaping stall §3.8, checkpoints §3.11).

On the side of Sequentia, when a cross-chain operation is executed, nodes should wait for the transaction to appear in a Bitcoin block before broadcasting the corresponding transaction in the Sequentia network, to make sure that the height of the Bitcoin block referenced by the Sequentia block with the cross-chain operation is equal or greater than the Bitcoin block with the corresponding operation.

To provide the right incentive for the Sequentia network to stay up to date with the Bitcoin network, leaders change with every Bitcoin block, leading to a new round of VRF outputs (while the committee composition itself is not affected by new Bitcoin blocks). Committee members will be likely to choose a new leader with every Bitcoin block, because winning the slot will depend on having the lowest VRF, weighted with a coefficient that significantly favors those referencing a Bitcoin block at a greater height.

It is possible to have a scenario in which some blocksigners in the current committee may be missing/offline, such that blocks cannot be certified, that is, reach a minimum amount of countersignatures; in this case, the chain will stall. For this reason, there is a set of conditions that allows the creation of valid blocks that do not meet the countersignature threshold, called the escaping stall rule:

If the last certified Sequentia block references a Bitcoin block at a depth of 4 Bitcoin blocks in the past (height h), a new Sequentia block can be certified without reaching the countersignature threshold if it references the hash of a bitcoin block at height h+3.

In the case of two competing blocks certified through the escaping stall clause, nodes will orphan the block with the lowest signature power, meaning the one that collected the fewest countersignatures from the committee. In the case of two blocks with the same number of countersignatures, the one proposed by the leader with the highest VRF is orphaned. In the case of two certified blocks, one through the escaping stall clause and the other meeting the signature threshold, the one certified through escaping stall is orphaned.

Another case also puts network liveness at risk: if the number of participants in the network is not sufficient to reach the minimum number of blocksigners in a committee (100 members). Initially, the minimum amount of Sequence tokens required to participate in the network as blocksigners is 40,000 SEQ (with an assumed supply cap of 400,000,000 SEQ). The minimum staking requirement constitutes an anti-spam threshold to avoid a more extended computation of the algorithm selecting the leaders, but it might be too high, especially in the exceptional case of an enforced consensus. Therefore, the “lowering staking requirement” rule applies:

If the number of participants is less than X, then the minimum amount of SEQ tokens required for staking is lowered.

If setting the threshold directly at zero might be used as an attack vector (i.e., flooding the network with participants staking very tiny amounts), then more complex logic could be implemented, like gradually lowering the threshold.

Anybody can run a Sequentia validator node, independently of the amount of SEQ at stake, exactly like a Bitcoin full node can function without holding any bitcoin and still process, validate, and accept transactions broadcast by the network. Also, stakers selected by the algorithm to act as block proposers cannot arbitrarily force, even if they form a majority, a Consensus rule change, just like bitcoin miners cannot force other nodes to upgrade their software.

In case a malicious majority attempts to change Consensus rules, accepting and countersigning blocks that are invalid for a minority of stakers, the enforce consensus rule applies:

If there exists a block b0 that breaks the consensus rules but is certified, meeting the quorum of countersignatures, then a valid block b1 at the same height of b0 can be certified with a new quorum representing the majority of the blocksigners that have not countersigned b0. If that quorum cannot be met and the hard-forked chain stalls, the escaping stall clause can be applied.

All SEQ tokens are pre-mined and distributed in the market at the mainnet launch, although most will have vesting conditions for a progressive release. Vesting tokens can be staked to gain transaction fees from the on-chain network activity despite not being transferrable, but no Sequence tokens will ever be generated ex novo.

The choice of entirely pre-mining tokens prevents inflation of the supply with coinbase generation, which would lead to the relative depreciation of SEQ tokens, and also furthers decentralization and provides a more direct and transparent way to assess the perceived value of the network. Inflation negatively affects holders of Proof-of-Stake governance tokens, but not stakers, who gain proportionally to what they already own from the generation of new tokens. Therefore, assuming that stakers are those with the most SEQ, if there was any generation of new tokens, the share of SEQ tokens would tend to be distributed towards those entities, leading to more centralization. The absence of inflation is, therefore, an effective measure to keep the network’s block production as decentralized as possible.

In addition, inflation would also provide perverse incentives to blocksigners that could lead them to break the slot time windows and accelerate the frequency of block production so that they can earn the coinbase transaction (newly generated tokens) in a shorter time window.

Finally, with no inflation, the value of Sequence tokens can be measured since the beginning based purely on network activity rather than the promise that SEQ earned through staking will be more valuable in the future. This more direct approach facilitates SEQ price discovery through the free market mechanism, which may contribute to mitigating typical pump-and-dump schemes.

We can expect many financial assets, like stock tokens and, in general, securities, financial instruments, or utility tokens, to have a much lower level of liquidity than Bitcoin, which represents a monetary medium. Therefore, second-layer solutions like the Lightning Network will not always be viable for all assets issued on Sequentia. In blockchains designed for tokenization, like Sequentia, on-chain transfers of various kinds of assets will likely remain a widespread use case. It also follows that the timing of on-chain transactions needs to be set to meet the market demand for faster on-chain payments than what is currently possible for Bitcoin. At the same time, block frequency must not be so high as to provoke issues like overlapping time slots.

With long-term sustainability in mind, the block size limit could be set to 0.5 MB so that, in theory, with a blocktime of 1 minute, the size of the blockchain could not grow by more than 262.5 GB per year even when fully saturated. Furthermore, a pruning system based on checkpoints, possibly combined with utreexo technology (used to reduce the size of UTXOs), can dramatically reduce storage hardware requirements even further.

In the former case, checkpoints can decrease the initial blockchain download time (IBD) for users wanting to run a node with a fast-sync mode (analogous to Pierre Rochard’s idea (7) of a node launcher for Bitcoin) and discard (prune) the blockchain before a certain block height so that the space required on disk remains minimal.

Thanks to these optimizations, running a full node on an average personal computer will always be possible, fostering a more decentralized network.

Footnotes/p3.10

7. With Pierre Rochard’s idea of “node launcher” for rapid onboarding, node functionalities are ready in the first minutes after launching the software. The wallet uses BIP157 while the Bitcoin full node is syncing in the background. Once the Bitcoin full node is ready, BIP157 usage stops and the wallet starts relying on its own blockchain data.

https://twitter.com/pierre_rochard/status/1104758721824067588 https://www.reddit.com/r/Bitcoin/comments/azrrc2/if_the_bip157_pull_request_gets_closed_too_then/ https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki

Synchronous protocols have defined time boundaries in which transactions and blocks are approved by specific nodes (usually, the leader in a round). However, the relativity of time for each node may produce convergence issues, causing a persistence problem (blocks are reorganized following an alternative chain). In asynchronous protocols, however, nodes approve transactions when a certain threshold number of nodes have acknowledged the block as valid. Consequently, they may have a liveness problem, stalling if the quorum is unmet. Sequentia solves permanent stalls with the so-called escaping stall clause, with the trade-off of potentially introducing a convergence problem. The possibility of certifying blocks through the escaping stall clause opens the possibility of divergences that might also be exploited as an attack vector. For example, long-range attacks with posterior corruption are possible in case the keys used for the cryptographic sortition of committee members and leaders are sold to a malicious attacker and reused in the future to perform an attack with nothing at stake. Therefore, checkpoints are enforced in Sequentia to protect the network from these potential issues, as described below.

Anyone can include a marker on the Bitcoin blockchain with the hash of a Sequentia block at any height (let us say height X). To this end, it is necessary to execute a Bitcoin transaction tx with an OP_RETURN and have this transaction be mined into a Bitcoin block. The block proposer generating a Sequentia block at height X+n with n as a positive integer is free to include a reference to said tx in that block. Other nodes will acknowledge the Sequentia block as a checkpoint request, distinguished from standard blocks precisely because it includes two hashes of the Bitcoin blockchain rather than only one. The checkpoint request is at height Z, equal to X+n, but the checkpoint will be enforced at height X. When a checkpoint is in place, a validator may prune the chain starting from height X.

Before nodes locally enforce a checkpoint, an event that we shall refer to as "checkpoint chain consolidation” shall occur. It will happen when nodes receive the 2016th confirmation on the Bitcoin network since block Z (in solar time, this corresponds to around two weeks): at that point, every Sequentia node configured to accept checkpoints will consolidate the blockchain up to block X, which means it does not allow rollbacks affecting the chain before that block, by placing a checkpoint on its local node. To reach 2016 blocks, nodes will only count new Bitcoin block hashes that appear after block X and which are also included in the header of a Sequentia block.

Note that the Bitcoin anchoring mechanism has a priority over checkpoints, so if a Sequentia block with a consolidated checkpoint references a Bitcoin block that is no longer valid, the checkpoint is also invalid. If a marker included in a Bitcoin transaction is orphaned from the Bitcoin blockchain, then the checkpoint associated with that marker is no longer valid in Sequentia. However, validators may prune the portion of the chain that is antecedent to the height of a consolidated checkpoint, so they might lose crucial information if Bitcoin reorganizes the chain at a greater depth than the checkpoint; this is why the checkpoint should be “buried deep enough” in the past. A depth of about two weeks (2016 Bitcoin blocks) may seem reasonable since a two-week reorganization in Bitcoin would be such a rare event that it would likely require manual intervention from the entire ecosystem, at least by miners, professional services, and sidechain nodes, among others.

The SEQ token lock-in period for network participants and the period required before a block producer can spend the block reward shall be longer than 2016 Bitcoin blocks. This ensures the correct game-theoretical incentives to follow the mainchain rather than trying to fork the network with long-range attacks.

All assets issued on Sequentia are referred to as RAS tokens. RAS is an acronym for Regular Asset on Sequentia, and it represents the specification for Sequentia fungible or non-fungible tokens (RAS NFTs). This standard features a typical list of rules that must be implemented to be correctly processed by a Sequentia wallet. Using this standard, every RAS can be received, sent, or stored in any Sequentia wallet.

When a RAS token is created, the issuer specifies the following rules:

• A maximum total token supply (if there is a cap).

• The number of tokens issued, including the address or addresses where they are held (usually the creation address) and the desired inflation scheme.

• Who or what can generate new tokens or burn existing tokens, e.g., a private key, a multi-signature, or other scripts.

• Access-Control-List rules (§4.5), if any.

• Whether the ACL rules are permanent or can be updated; in the latter case, the conditions for an update (e.g., script, keys).

• Whether the total supply/inflation scheme is permanent or can be updated (and, in the latter case, the conditions for an update).

RAS tokens, including SEQ, are transferred solely on the Sequentia sidechain and, therefore, do not pollute the Bitcoin blockchain.

The RAS standard supports Bitcoin script extended with Access Control List rules. Bitcoin script enables transaction batching and grouping multiple payments in a single transaction, even using different tokens. It also allows HTLC contracts, including:

• Lightning network payments, including through routes opened in different tokens (assets at the edges)

• Atomic swaps and other swap contracts using Lightning, which may also be referred to as “Lightning swaps” or (when not all swapped assets are on Lightning) "Submarine swaps".

It is possible to wrap tokens from other chains on Sequentia: the entity managing the peg-in will lock in funds on the main blockchain, which creates a corresponding amount of RAS tokens. Peg-in federations (8) or other models governing the issuance of wrapped tokens can also be implemented. Pegging out of the wrapped token can be done by burning RAS tokens, provided that the entity governing the peg-in unlocks the corresponding tokens on the main network.

Developers can use a combination of ACL and oracles to create sophisticated smart contracts on the Sequentia chain and bind the issuance or existence of RAS tokens to a corresponding amount locked on other blockchains or even out of the digital realm.

Footnotes/p4.2

8. Such as the Strong Federation mode: https://blockstream.com/strong-federations.pdf

Tokenizing securities means representing an ownership right (such as shares in a company or a credit) through a token. This right is usually guaranteed by the token issuer, who is contractually bound to recognize the token as a bearer security. These kinds of tokens are often referred to as “stock tokens”. The token may also grant administrative rights corresponding to company shares, where the token holder exercises his rights cryptographically and pseudonymously by demonstrating ownership of the security using his private key.

A token can also represent an asset in the issuer’s custody, for example, stablecoins, which have fiat money (such as the US dollar) as their underlying asset. In theory, stablecoins can be included within the broader definition of security tokens, although in some jurisdictions, the classification may be different for legal reasons.

While cryptocurrencies like Bitcoin can be issued in a decentralized way, the issuance of securities is always centralized, meaning the issuing entity is also prosecutable by authorities or other entities. Despite this, the advantage of a blockchain for securities is evident: the blockchain is the first technology capable of transferring bearer securities in digital form without relying on a centralized system. In other words, whereas the issuance of a security may always intrinsically be centralized, there is, however, great value in disintermediating the custody of securities, as well as the clearing and settlement of securities trading, i.e., allowing securities to be bought and sold for cryptocurrencies (e.g., Bitcoin), directly through a DEX, without requiring agents, brokers, exchanges or other intermediaries.

Sequentia’s architecture includes the Access-Control-List (ACL) tool for developing disintermediated finance with particular regard for securities. It is possible to picture a future in which companies or self-employed people freely issue shares or bonds on a blockchain and then transfer them without friction. Private arbitrators elected by involved parties could then be responsible for handling fraud cases against the token issuer and enforcing rules through ACL. Examples of fraud cases might be:

• When business profits are not redistributed as scheduled based on the distribution of the assigned tokens;

• When administrative rights associated with the token are denied;

• Modifications to the supply (inflation) of the token that do not meet the expected schedule or when tokens are burned/locked by the issuer against the terms of the public offering.

Some of these schemes might be prevented if the RAS token representing the security is issued without the possibility for the token issuer to intervene in factors such as the generation of new tokens (inflation control). However, such rigidity may often not be well-suited for regulated securities, and a free market is better capable of providing correct incentives; when serious disputes arise, the token’s digital nature and the total absence of frictions in exchanges would immediately lead to a fall in its value, undermining the issuer’s credibility.

Lightning network is enabled for all fungible RAS tokens. Sequentia’s Lightning Network wallet functionalities use the same BOLT specifications meant for Bitcoin. It is possible to make an on-chain transaction by opening a payment channel in a token issued on Sequentia, and then all the following payments in that token can be made through that channel. Indeed, the channel can also be used as a route for the payments of other users, even in different tokens.

Lightning Network payments are expected to be used on Sequentia, particularly with stablecoin transactions, since they have high liquidity and are frequently transferred between custodial services/exchanges with better means of creating well-balanced channels than the average users. However, in the future, even tokens with lower liquidity might take advantage of the Lightning routes built for Bitcoin (or any stablecoin with enough broad adoption) to be exchanged as assets at the edges with multi-hop transfers.

Let us assume well-developed Lightning payment routes exist for Bitcoin, or any other token like a highly liquid stablecoin (let us say S-USD). Then, building an entirely new network for any other RAS token is unnecessary since any asset can use the BTC or S-USD routes as a backbone for its transactions.

Imagine Alice wants to transfer a RAS utility token (let us call it UTL) to Eve for a value of 50$. Alice and Eve have no open Lightning channels between them with any token. However, Alice has an open channel with Bob in UTL, Bob has an open channel in BTC with Charlie, Charlie has an open channel in S-USD with Dave, and Dave, in turn, has an open channel with Eve in UTL. All channels have enough liquidity to allow a transfer of value for 50$ (though it is expressed in different tokens).

At this point, Alice can use the route between Bob and Charlie in BTC and the route between Charlie and Dave in S-USD to transfer UTL to Dave. How does it work? Alice sends $50 worth of UTL to Bob in their Lightning channel. Bob charges Alice a small fee and sends Charlie $50 worth of BTC. Charlie charges a small fee and sends $50 worth of S-USD to Dave, who, in turn, charges a small fee and sends $50 worth of UTL to Eve.

At the end of the process, Bob, Charlie, and Dave each have more UTL, BTC, and S-USD, respectively, in their balance than before, but their total balance value in US dollars has not changed, except they earned a little routing fee paid by Alice. Alice successfully transferred UTL to Dave despite having no Lightning channel open between them in RAS tokens.

Through this routing with “assets at the edges,” it is possible to route any number of assets, removing the need to bootstrap an entirely new network for any new asset. This allows for a broader multi-asset Lightning Network leveraging existing Bitcoin infrastructure. In the case above, UTL is at the edges, utilizing a pre-existing route in BTC on the Bitcoin network and S-USD on the Sequentia network.

Another potentially revolutionary use case for the Lightning Network with RAS tokens is the high-frequency, low-cost peer-to-peer trading of stablecoins, utility, and security tokens against BTC or each other. The section dedicated to Lightning Network swaps (see §5.2) explains this in further detail.

In the Bitcoin ecosystem, several big companies were late in introducing batching procedures due to the technical complexities required to aggregate transactions manually. For this reason, designing applications that assist users with this task is preferable.

That is why a Sequentia wallet should include two different tools to incentivize the use of batching:

1. A dedicated user interface that services/businesses like exchanges can use to perform large-scale transaction batching (of any RAS token).

Users can ask peers to aggregate payments in a single transaction, extending batching procedures to every user, not only services and exchanges that process many payments simultaneously. Users can aggregate transactions made in different RAS tokens and use signature aggregation to reduce the size of each payment.

Footnotes/p4.4

10. For example, Wasabi wallet implements the function of transaction coinjoin, which batch payments of the same amount so that the blockchain analysis cannot individuate the sender and receiver’s addresses.

11. When Coinbase introduced batching in March 2020, their load on the Bitcoin network was reduced by “more than 50%”, as reported by Eli Haims, Coinbase product manager. That 50% saving in space led to an actual 75.2% saving in fees (https://blog.coinbase.com/coinbase-rolls-out-bitcoin-transaction-batching-5f6d09b8b045 https://www.cryptoglobe.com/latest/2020/08/coinbase-saved-its-clients-75-in-fees-by-batching-bitcoin-transactions).

Access-Control-Lists (ACLs) are specific limitations that can be enforced on transactions of a given token. ACLs make it possible to issue or update security tokens in compliance with company policies or other legal requirements: receiving addresses can be whitelisted or blacklisted, and in general, ACLs provide conditions on how tokens can be spent, determining how non-fungible the token is. For example, they can make it impossible to transfer a certain amount of tokens per transaction under a minimum or over a maximum threshold or enforce a time lock that limits the token’s transferability at a particular time.

ACL conditions can be implemented on RAS tokens, and token issuers can update these conditions merely by creating a new transaction on Sequentia containing the updated rules. Such centralized governance of ACL rules is possible only if it is established in the set of rules originating from the token’s creation. To update an ACL, token issuers could also require executing a particular script or signing a transaction with a particular set of keys (such as n of m multi-sig).

Access-Control-Lists (ACLs) act as a filter dedicated to limiting the transferability properties of a token. By default, any address can transfer and use a token without limitations unless the token creator defined some ACL during its issuance. Among the rules to be defined, token issuers should decide on the possibility (or impossibility) of changing the ACL rules in the future, such as once the token has been issued on the network, as well as whether some rules should be changeable while others are not, and to whom the rights to change the rules (if any) should be conferred.

One possible purpose of ACLs is to enable peer-to-peer trading and transfer of security tokens that need to comply with particular company policies or legislation. Different limits can be enforced on a transaction’s input or output.

On the input side:

1. It is possible to enforce an upper or lower bound on the amount transferred;

2. Timelocks can be enforced (i.e., the UTXO cannot be spent until block x);

3. A particular address can be blocked so that all UTXOs from that address are frozen and cannot be transferred.

On the output side, it is possible to make it so:

1. Only specific addresses can receive a transaction: in this case, the standard policy is to deny the transaction unless the requirement is met (the output address is whitelisted);

2. A specific address cannot receive a transaction: in this case, the standard policy is to allow any transaction unless the restriction is met (the output address is blacklisted);

3. A particular address can or cannot receive the transaction depending on the amount transferred (upper or lower bounds) or the lock time (Conditional whitelisting/blacklisting);

From a technical point of view, the rules are enforced through one or a series of filters and an action: allow, deny, or check:

• If the action is ‘deny’, and at least one of the filters is met, then the transaction cannot be validated;

• In the case of the ‘allow’ action, the transaction can be validated only if all the filters are met;

• In the case of the ‘check’ action, the transaction is validated only if it meets another set of rules used for another token. The check action can be used in case of multiple tokens issued with the same policy conditions or if more tokens share a standard set of rules (recalled with check), on top of which other rules are enforced for each different token. For example, the token issuer can specify or inherit an ACL already defined by a trusted third party in charge of AML/KYC procedures.

An additional control parameter can be configured when a particular entity needs to approve each token transfer. The entity is defined as a “controller” and shall “countersign” the transaction for validation. The difference with a simple 2-of-2 multi-signature is that this ACL control rule requiring the controller’s signature can be combined with other ACL rules or any other desired multi-signature scheme for the UTXO. For example, users might use a 3-of-5 multi-sig account to hold the tokens, which can only be transferred by providing at least 3 signatures together with the controller’s signature (so that it effectively becomes a 4-of-6 scheme) and whatever other ACL rules are configured for that token. The controller can be the token issuer, a service, an identity provider, or, more generically, an oracle.

Generally, the scripts contained in ACL rules are relatively small, making them manageable for nodes to validate. They do not require much space in terms of storage unless it is necessary to blacklist and whitelist multiple addresses. For this reason, there are three different possible implementations of ACL for blacklisting and whitelisting to choose from depending on scalability considerations, such as based on the number of addresses to be blacklisted or whitelisted, as well as the expected frequency of transactions in tokens complying with ACL rules:

1. The list of addresses can be held off-chain by a third party that will countersign any whitelisted (or not blacklisted) transaction, like in a traditional multi-signature scheme.

2. The list of addresses can be written in one or more on-chain transactions. Each validator will then check if the transaction is valid according to this set of addresses, checking all transactions and blocks and adding or deleting whitelisted or blacklisted addresses to a particular ACL rule.

3. The list of addresses can be held off-chain by one or multiple third parties, possibly in a distributed hash table that users can freely sync. Not storing the list on-chain means the blockchain is not burdened with more data and may also help keep the list of addresses private. The list of addresses is a Merkleized binary trie (12), whose root is the only piece saved in on-chain (13) transactions containing the ACL rule, and that can be updated in the future. Each user making a transaction then needs to provide (in that same transaction) proof that the address is in the Merkleized binary trie through a Merkle audit proof (14). Therefore, the burden of proof is with users sending transactions according to their respective ACL, rather than each validator node, without weighing on the blockchain.

The first solution (countersigning each transaction) grants more scalability but requires an always-online third-party node to sign transactions.

The second solution is feasible only if the list of addresses is small and changes infrequently. Assuming a public key is 256bit, 15 whitelisted public keys weigh around 3.8KB. If, instead, the list is made of 1,000 or 10,000 elements, the cost for on-chain transaction(s) to store and maintain this list on-chain goes against any reasonable principle of scalability.

The third solution is appropriate when the number of addresses is extensive whilst the number of expected transactions in tokens complying with those rules is relatively infrequent, and/or the transactions’ value will be high enough to justify a higher-than-average fee. With this solution, it is enough to store the Merkle root on-chain rather than the entire list of addresses, making it very efficient in terms of storage. However, each transaction must carry a proof showing that it is valid, containing the Merkle audit path that proves the whitelisted address is in a leaf of the Merkle tree. The Merkle audit path is the shortest list of additional nodes in the tree required to compute the root hash for that tree. To verify that a leaf node belongs to a tree, it is only necessary to know the direct neighbouring leaf node’s hash, if any, and the neighbouring parent node hashes directly above the leaf nodes.

For example, to prove that leaf “7” is in the Merkle tree (see the figure below), it is only necessary to know leaf 8, H(C), and H(A,B). For a list of only eight addresses like this (the leaves), the Merkleized structure is inefficient: storing all addresses on-chain is better than requiring a proof that utilizes the Merkle audit path for each transaction.

However, a Merkle tree of 1 million addresses requires only 20 steps to reach the leaf from the root (15). Therefore, a high number of whitelisted addresses is feasible if transactions in that token are not that frequent and all have a relatively high value, for which it is reasonable to pay an above-average fee.

A proof that a particular element is in a tree takes O(n) time to construct where n is the number of elements in the Merkle tree but then takes only O(log n) space to store and O(log n) time to verify (16).

Footnotes/p4.5

12. https://bitcoin.stackexchange.com/questions/51423/how-do-you-create-a-merkle-tree-that-lets-you-insert-and-delete-elements-without?rq=1

13. Example of merkle tree for whitelisting in Ethereum NFTs: https://medium.com/@ItsCuzzo/using-merkle-trees-for-nft-whitelists-523b58ada3f9

14. https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/merkle-tree/merkle-tree.html

15. https://www.derpturkey.com/merkle-tree-construction-and-proof-of-inclusion/

16. https://bitcoin.stackexchange.com/questions/49489/algorithm-of-checking-whether-an-element-is-present-in-a-merkle-tree

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.

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.

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

A Sequentia DEX has two main components: a messaging system and a trading engine. The messaging system collects user trade intentions (orders) and sends them to the trading engine that checks the orders and executes them.

A DEX may fail to be censorship-resistant due to any of the two following distinct single points of failure:

1. When the trading engine is prone to attack vectors, for example, if there is an identifiable owner of the private key/address who manages the smart contract and who, in some cases, has the power to stop it;

In theory, Sequentia supports several different types of DEX interactions, depending on the needs or preferences of users in terms of decentralization, privacy, and censorship resistance: from a fully decentralized solution (in terms of both the trading engine and the messaging system) to milder solutions that introduce intermediaries in the communication in order to increase the spectrum of possible trades.

Footnotes/p5

18. Most DEXs today are implemented with a web interface: one famous example is EtherDelta, where to access its functionalities, a user had to go through etherdelta.com. The website then talks to the browser’s extension MetaMask, which receives and sends the information from and to the Ethereum network. In 2018, the SEC fined EtherDelta’s founder for operating an unregistered Security Exchange, which resulted in the exchange suspending its operations.

In general, an atomic swap transaction allows two users to exchange tokens between different blockchains (inter-chain) or even from the same blockchain (intra-chain) in case the blockchain supports multiple tokens. Atomic swaps are Hashed TimeLock Contracts (HTLC) using Bitcoin script. Sequentia wallets that are also Bitcoin wallets can manage an atomic swap both in the Bitcoin network and in the Sequentia network; therefore, it implements atomic swaps for both cross-chain DEX transactions (between BTC and RAS tokens) and intra-chain transactions (between RAS tokens).

I. User A creates a transaction tx1 on the Bitcoin network, sending an amount of BTC to user B. The transaction output has some specific conditions:

1. B can grab the coins within a specific timeframe (e.g., 6 Bitcoin blocks). Otherwise, A can get the coins back.

2. To make sure A can get the coins back in case B does not claim the money and the exchange does not happen, a second transaction is created: before A broadcasts tx1, B signs a second transaction which would send back the coins to A after a larger time frame than the locktime of the tx1 (e.g., 9 Bitcoin blocks). B can technically sign this child transaction even if the parent is unknown.

3. A broadcasts tx1 (only after B signs the child transaction and passes that to A) which may be included in a forthcoming Bitcoin block.

4. The only condition for B to be able to spend the output of tx1 within 6 Bitcoin blocks is to claim them before A, which is possible only if B knows a “secret” X revealed by A himself.

II. B does not know the secret X, but A sends the result of a hash function of that secret h(x) to B.

III: User B creates a transaction tx2 on the Sequentia network, sending S-USD to user A in exchange for the BTC. The transaction output has some specific conditions

1. A can grab the output of tx2 within a specific timeframe (about 4 Bitcoin blocks, calculated on the Sequentia network thanks to the anchoring system). Otherwise, B can get his coins back.

2. Before B broadcasts tx2, A signs a child transaction that would send back the coins to B after a larger timeframe (e.g., 7 Bitcoin blocks).

3. The only condition that allows A to spend those coins within 3 Bitcoin blocks is to reveal the secret. The “key” to unlock the transaction’s output is the secret X.

A must reveal X to grab the coins sent by B and has about 3 Bitcoin blocks to do so. Once A grabs the coins, B knows the secret X and can take the BTC sent by A.

Even if A reveals the secret at the very last minute to be included in the 3rd Bitcoin block, B has an additional 3 Bitcoin blocks to claim the BTC sent by A since the locktime for the first transaction’s output is 6 Bitcoin blocks instead of 3.

If A does not reveal the coins, both users will get their assets back within 6 Bitcoin blocks (B) and 9 Bitcoin blocks (A). If everything goes as expected, both users will receive the coins in the first blocks validated on the respective chain (Bitcoin and Sequentia), which will happen on average 5-10 minutes after tx1 is broadcasted to the network.

The only flaw of a traditional cross-chain atomic swap is that the time lock cannot be reliable, as one of the blockchains may be lagging behind due to hashrate variability. Depending on specific blockchain structures and rules, possible reorganizations or other factors may also come into play. Therefore, the LockTime parameters used in the two chains are inadequate to represent frames in solar time, which, if broken, may allow malicious play by the parties exchanging tokens. For this reason, atomic swaps generally require very large time frames in the range of 12-24 hours. If something goes wrong (e.g., one of the parties disappears), recovering funds might require an entire day.

Sequentia bypasses these issues by introducing the first reliable timeframes for cross-chain Bitcoin atomic swaps. Since it is structured as a Bitcoin sidechain, each Sequentia block carries a reference to the Bitcoin blockchain. The nLockTime of the two transactions returning the tokensto the sender is calculated in the exact number of Bitcoin blocks counted on both chains. Furthermore, thanks to the anchoring system between Sequentia blocks and Bitcoin blocks, cross-chain atomic swaps are secure even in case of reorg (chain reorganization): if a reorganization happens on Bitcoin, the Sequentia chain reorganizes, too, as part of the consensus mechanism.

Finally, the UTXO structure with Bitcoin script allows wallets to implement CPFP (child pays for parent) functionality, speeding up atomic swap transactions if they are stuck in the mempool due to too low fees. Wallets may even query a watchtower (controlled by the user or by a service provider/oracle) to notify the user when the transaction spending output is late, and then suggest a proper CPFP transaction fee amount.

An atomic swap smart contract performs the role of the trading engine in a DEX transaction and can be combined with any type of communication system to manage the orders and potentially even direct communication via private message: each party simply needs to specify the node id of their wallet to connect each other, initiating the swap. This solution is likely the best choice for OTC trades as it requires both parties to already be in contact and agree on the pair exchange details, like the precise amount of tokens and the relative price.

Privacy is guaranteed because no one needs to know about the transaction except the two parties involved, whereas blockchain analysis cannot distinguish an atomic swap from any other transaction in the blockchain.

Order packages can be integrated into the functionality of a Sequentia wallet to trigger Lightning Network transactions. When a user wants to execute a trade, their wallet recognizes the Lightning Network swap’s specific request, thanks to a specific parameter lightningSwap. It also automatically produces payment invoices and HTLC transactions according to that order request (detailing the exchange rate, amount of tokens, and expiration time).

This solution can be used for directly trading BTC against RAS tokens or trading RAS tokens against each other.

The swap can be executed only if both parties have already established a channel in both exchange pairs. However, these channels do not need to be established directly if there is a Lightning route between them, allowing “assets at the edges” payments (§4.3).

1. Bob produces an order package asking for an amount (valueB) of tokenB in exchange for an amount (valueA) of tokenA and sends it to Alice.

2. Alice receives the order package, produces a Lightning Network payment invoice (A) for tokenA, and passes the invoice to Bob.

3. Bob creates an invoice (B) for tokenB, whose output can be redeemed only by revealing a secret (HTLC contract).

4. Bob creates a conditional payment to Alice’s invoice (A), hash-locked with the same secret required to redeem the tokenB output paid to invoice B.

5. Alice pays the invoice (B) by passing the amount (valueB) of tokenB to Bob, as he requested in the order package.

6. Bob redeems the payment executed by Alice, revealing the secret.

7. Alice can now redeem the conditional payment sent to invoice A.

The benefits of Lightning Network DEX transactions are speed, privacy, near-zero fees, and no on-chain pollution, with the only limitation that it requires the existence of two different channels (for both the tokens exchanged).

Atomic swaps and Lightning swaps are trading engines that can be coupled with a peer-to-peer communication system that allows swaps between parties that are unknown to each other and have had no prior contact. It is also possible to create multiple swaps splitting a single order into multiple sub-orders, increasing the possibility of finding a match in terms of the amount and price for the pair requested.

Each order represents a trading intention packaged in a message containing order parameters concatenated and hashed to 32 bytes using the Keccak SHA3 function. The maker signs the order with the private key associated with his node id.

Once packaged, the order can be sent to the recipient using whatever medium of communication, even a direct message (e.g., via email or a messaging application) or a DHT (§5.4). The communication system can also work on a TOR network so that users can communicate directly without exposing each other’s IP addresses.

The message might be structured as follows (19):

The data contained in the order does not reveal confidential information that directly relates to the maker except for the maker’s node id, which is necessary for the taker(s) to get in touch and perform the transaction.

In some sense, both users involved in an exchange can be labeled as both “maker” and “taker” since the order can only be executed when there is a match between two “maker” offers expressed in the same pair (but in the opposite direction) and which are consistent in terms of amount and price range.

There is an expiration time when the offer is no longer considered valid in terms of Bitcoin block height, and the wallet will reject any match proposed by other nodes.

Some orders are dropped by the nodes who created them, while others are closed because the swap has already been finalized. To notify peers of closed or canceled orders, it is necessary to prove these orders’ ownership by signing a message with the private key connected to the original order creator. Nodes also notify their peers by relaying messages about closed orders.

Two additional parameters are introduced to increase the chances of having a match between maker and taker, both freely configurable by the user:

1. multipartySwap: it is expected that the amount of tokens requested for the swap is not easily matched in the market with an equal and opposite order expressed in the same pairs. Therefore, it might be necessary to split the amount into smaller orders performed by different users in a “multi-party swap” to fulfill an order. For example, the maker can send 0.4 BTC to user1, 0.2 BTC to user2, and 0.4 BTC to user3, creating three different swaps. The trade-off in the case of atomic swaps (but not lightning swaps) is that several exchange transactions require more fees to be paid on-chain, and users are not willing to create so much dust. Therefore, the maker can introduce a threshold in the number of tokens exchanged in the atomic swap, under which any exchange request would be rejected. If the parameter is set equal to valueA, the maker intends to perform a single atomic swap and exchange the entire amount of tokenA. If the parameter is different, it represents an arbitrary value equal to or below half of the valueA, which indicates the minimum amount accepted for every single swap with other users. The lower the parameter is set, the higher the chances of finding a match, but fees and dust increase. On the other hand, if the parameter is high, failure is probable in finalizing the order (i.e., only a few orders find a match and execute).

2. priceRange: indicates the deviation from the actual price in the offer that the maker might accept. For example, if tokenA is BTC, and tokenB is S-USD, and the ratio between valueA and valueB is 1/10.000, then a 1% priceRange means that the maker is willing to accept a swap transaction for any amount of S-USD that is higher than 9,900 S-USD in exchange for a single BTC. By default, each node accepts whatever more favorable price ratio, so the priceRange deviation is calculated only for higher tokenA/tokenB ratios than what is indicated by the maker (which is usually the price suggested by the wallet). Accepting a slight variability in price levels makes it much more likely to find a match on the DEX but may also imply less advantageous trades. By default, the wallet picks up the most favorable price among the matches.

A swap transaction is necessarily bilateral, meaning that both involved users must be online and agree on the exact amount of tokens that shall be exchanged. This could cause issues since it is unlikely to find an exact match between maker and taker at precisely the same moment. In case of low liquidity of a specific asset, users might be unsure about the possibility of finalizing a big order for its entire amount, so it shall be split into many different swaps. Therefore users may choose between different configurations of their node. A standard configuration might allow a swap to be automatically initiated with the first user available for whatever amount equal to or greater than the amount indicated in the multipartySwap parameter.

Otherwise, a user may decide that no swap shall ever be initiated unless there are enough matches to close the entire order and the corresponding users are all online at a specific moment. Users may be considered online when they positively confirm the reception of a message at the end of some time interval. This option minimizes the possibility of starting a multi-party swap without finalizing it. The trade-off is that it may also slow down the process or end up with the exchange transaction stuck at the very beginning.

A solution in the middle is that even if nodes have not checked if counterparties are available to initiate a swap, it is enough to check that there are enough matches in the market to finalize the order for its entire amount because there are enough corresponding non-expired and non-closed ordered packages.

In the presence of multiple available offers, wallets will choose the ones closest to the amount requested and at the most favorable price to reduce the number of swap transactions required and reduce the spread paid on the exchange rate.

Carrying out the reconciliation process between offer and demand without a centralized order book is challenging. Luckily, there are good market incentives for professional operators to intervene in this mechanism as takers, capturing most of the users’ offers in the market, as described in §5.5.

Footnotes/p5.3

19. It is freely inspired by 0x open protocol from the Ethereum network https://0x.org/pdfs/0x_white_paper.pdf

Sequentia’s hitherto described DEX capabilities mostly use technologies that assume the parties involved are already in contact when transferring money. However, to build a real marketplace, users must also be able to find one another without knowing each other in advance; a communication system is needed to allow them to choose between different orders waiting to be fulfilled in the market.

Therefore, we propose a system wherein orders are broadcast and stored by nodes in a decentralized manner using a distributed hash table (DHT). Every Sequentia user or operator can activate the DHT-DEX functionality: DHT nodes are free to sync the full DHT, prune it, and start partial sync only when they are online (starting from the most recent orders) or not sync at all. Once activated, the user’s node starts syncing the Distributed Hash Table of orders from its peers. The wallet looks at the DHT for possible matches until it finds the first user online, then initiates an atomic swap.

Not all orders broadcast in the network that reach the peer are registered on the hash table; instead, each node stores only those orders that are filtered based on their interest and will pass on to the network only what is stored, just as on BitTorrent or other similar peer-to-peer systems. A bigger DHT grants more opportunities to find a successful match but, on the other hand, requires more time and resources to be synched and stored.

This means that all nodes will never share a single, identical DHT, and also that there will likely never be any nodes who know or store the entire order book history since the complete set of orders is stored only collectively in many fragmented tables in possession of different node owners.

The filters applied in the syncing phase can be set over a chosen pair, a price range, or the amount requested in the transaction. Nodes can freely prune unwelcome orders from their DHT, also preventing them from being relayed to other nodes. Some nodes may prune the expired and closed orders; others may keep them to elaborate statistics or better recognize spam.

An anti-spam filter is necessary because an attacker could populate the DHT with fake orders. For this reason, each node can configure anti-spam filters, removing orders from nodes known to spread a suspiciously high amount of orders that are never fulfilled, closed, or canceled. If the anti-spam filters prove insufficient to manage a vast amount of fake orders or require too many resources, a third party can intermediate the synchronization of the DHT (see §5.6).

Users may rely on a price ratio suggested directly by the node wallet when creating an order. The user would then choose between two indicators:

a) the price provided by a centralized exchange/service through an API or

b) the price retrieved from the DHT, which is calculated in a fully decentralized manner.

A messaging system based on a distributed hash table (DHT) has a few drawbacks:

1. Speed and efficiency are far below what a centralized server can provide;

2. It might be too heavy and resource-draining, especially for mobile devices, considering what an average user is willing to dedicate towards this purpose;

3. It is impossible to know exactly when an order is closed since the atomic swap is bilateral, meaning that users cannot remove orders from the DHT unless confirmation is already provided by the order’s owner. This may lead to a huge number of message requests/responses between concurrent users that match each other even if some have already finalized the exchange transaction. Moreover, some orders might be left unmanaged by users (e.g., the user broadcasted them but went offline afterward or never finalized the atomic swap for any reason). Even if wallets can filter them, these orders can cause the DHT to become bloated with useless data;

4. It leaves room for spam attacks: an attacker could populate the Sequentia DEX with fake orders. This attack would be free and could disrupt the network if not promptly recognized and banned by the other nodes.

For these reasons, specialized nodes can intermediate the messaging system as described in §5.6.

The privacy and immediacy granted by the aforedescribed Sequentia DEX compared to a centralized exchange can be factored in the order packages, expressed by the priceRange parameter. That is, even if it is cheaper to trade on a CEX, a DEX has added value.

When liquidity is low, professional traders will grab all maker offers with large enough spread relative to CEX prices. When liquidity is high, the mark-up will be enticing enough to incentivize new market operators to join the business, lowering the premium required to fulfill orders.

To elaborate, let us say a user broadcasts an order on the DHT, which also expresses the “priceRange” parameter, a percentage of deviation from the limit price defined in the order, which increases the possibility of finding a suitable match. Specialized entities (which we may call “liquidity providers”) can always inspect the DHT to discern speculatory opportunities by fulfilling orders on the DEX since they can profit from arbitrage between DEX and CEX prices.

Once a new order appears, the liquidity provider can connect to the corresponding user and offer a symmetric order with a limit price within the priceRange of the DHT order, but with a more convenient price ratio (for the liquidity provider) compared with a centralized exchange.

Suppose the DHT order book’s trading pairs are expressed in a token listed on major centralized exchanges (such as BTC or a stablecoin). In that case, it is plausible that liquidity providers will always have enough tokens to fulfill the match as they can instantly buy them on a centralized exchange using the Lightning Network.

Assuming that liquidity providers already have channels entering or exiting centralized exchanges for all RAS tokens with high liquidity, they will likely develop BOTs that would query prices and orders on the DHT and simultaneously operate DEX and CEX to profit from the arbitrage opportunities faster than competitors.

In short, users buying assets on a DEX pay a premium over the same type of trade done on a centralized platform. In exchange, they maintain complete privacy, do not need to pass KYC/AML procedures, deal with legislation and authorities, or trust any third-party custodian service.

Liquidity providers allow users to find a match for their orders immediately. In return, they can speculate by leveraging that premium and simultaneously operating on DEX and CEX through the Lightning Network. Competition between liquidity providers lowers the premium paid by users.

The order package preceding a swap is a message that might need to be relayed throughout the network before reaching a match. This would take time and resources and expose the relayer nodes to spam attacks. For this reason, nodes may subscribe to “watchtower” services, which perform a quality check for their subscribers. A watchtower stores the DHT and a few additional pieces of information provided by nodes connected to them to report the latest status of orders.

A watchtower checks the status and the frequency of the operations to create a rank, which increases according to the number of finalized operations, i.e., when both users involved confirm that a swap was successfully achieved. The watchtower cross-checks the DHT order book with the subscribers’ data, proving that the transactions are successfully executed. If the trade happens through an atomic swap, the watchtower also performs blockchain analysis to determine each user’s reliability.

A watchtower ranks the user and their associated orders, communicating information to each subscriber about the estimated reliability of a particular order/node, reporting spam, and notifying closed or pending orders from inactive peers. It may also relay orders to the subscriber after they have already been filtered according to their interests and sorted according to ranking. Wallets can accept or reject connections with other peers based on their reported reputation. This way, users syncing the DHT may leave aside useless data or decide not to initiate a particular swap transaction if the counterparty is not “verified” by the watchtower.

A watchtower could require a payment fee for its services. However, in theory it could also operate for free if, for example, it is operated by an entity that somehow benefits from developing a reliable DEX, like a service provider that monetizes complimentary services connected to the DEX. Moreover, given that the watchtower privately gathers data from users, it also disposes of more resources for elaborating DEX statistics, which may have an economic value or grant reputational value, allowing further monetization through advertising, for example.

A watchtower also collects information such as price and timestamp about orders that led to successful swaps. Keeping track of this data may facilitate the calculation of each pair’s price ratio on the DEX: not only estimated values from the order book but actual prices of the last exchange performed on-chain.

Relying on a watchtower’s services does not require much trust: even if it is shut down, communication between peers is not interrupted, nor does the watchtower influence the swaps that are going to be performed; it only facilitates communication between peers. The trade-off is some loss of privacy since the watchtower can distinguish on-chain transactions associated with atomic swaps in the DEX, thus flagging them as belonging to a particular owner and tracking down each ownership transfer.

A more invasive solution to avoid the drawbacks of a DHT constructed in a peer-to-peer fashion is to trust special relayer nodes that act as book aggregators, store the DHT and broadcast the orders on behalf of the users. This would be particularly helpful for light node/mobile wallet users as they may not have time and resources to sync many megabytes of orders or sort and filter them.

When users intend to exchange tokens, a Sequentia wallet can use bloom-filters to ask a book aggregator for orders matching a specific trading pair. Then, relayer nodes provide an answer – a list of all the orders in the network that may be of interest (in terms of price and amount), already filtered or ordered according to rankings. It also combines matches between simultaneous online users, directly suggesting how to initiate atomic swap transactions and what parties can be involved. When a wallet finalizes an order for an entire amount, the book aggregator is notified so that no more matches are proposed.

Book aggregators can be paid using three specific fields in the order package:

• feeRecipient: the address of the book aggregator;

• feeToken: the token used to pay the book aggregator;

• feeAmount: the fee amount sent to the relayer.

Given that book aggregators centralize the communication system in a single entity, no exchange can happen if the aggregator is shut down until nodes find an alternative book aggregator or start syncing the DHT on their own. However, aggregators might also be highly efficient in finding matches and achieving a prolific market of exchange transactions.

The essential difference between a book aggregator and a centralized exchange is that:

1. It is a non-custodial solution;

2. the trading engine remains a trustless atomic swap or lightning swap;

3. users identify themselves using pseudonyms.

There is no correct choice between a DHT synchronized independently or a book aggregator; the best solution depends on the degree of trust the user is willing to give third parties and the confidentiality required for their trades.

Nothing in this document shall be deemed to constitute a prospectus of any sort, or an invitation, or a solicitation for investment, nor does it in any way pertain to an offering, invitation, or solicitation of an offer to purchase any security, ownership right, stake, share, future revenue, company participation, or other equivalent rights in any jurisdiction. Information in this document also does not constitute a recommendation by any person to purchase tokens, currencies, or any other cryptographic assets; neither the Issuer has authorized any person to provide any recommendations of such kind. Observations contained in this document may constitute forward-looking statements or speak of future events or plans. Such forward-looking statements or information involve known and unknown risks and uncertainties, which may cause occurring events to be different. Errors, inaccuracy, or omissions may also occur in any such statements or information. Accordingly, no reliance should be placed on any such forward-looking statements or information, and all Issuer liabilities are disclaimed.