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.

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).

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)

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.

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.

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.