Protocol Overview

Glittr is designed to allow for Smart Contracts as natively to Bitcoin as possible. Glittr makes carefully considered tradeoffs to provide a robustly decentralized and trust-minimized platform which replicates many of the benefits of EVM without sacrificing on Bitcoin nativity.

Glittr is not an app, and we don't believe in telling people how they should build their apps. Therefore, the protocol is designed to allow for a great degree of flexibility so that developers can make the right choices for their users.

No VM

Many programmability solutions for Bitcoin provide a bridge to a VM-based environment. And inherent issue with this structure is that it introduces significant new trust assumptions, namely on the bridge and the VM operator.

Further, allowing for arbitrary computations requires that gas fees can be charged proportionately to compute. Bitcoin fees operate on a market system - 100% of fees a user allocates to miners are given to the miners; in ETH's account model, users specify a maximum amount of gas but can be charged only what is used. Allowing for arbitrary compute on Bitcoin either necessitates an account model on an L2 or creates the risk of significant volumes of failed contract calls and serious MEV concerns.

Glittr instead relies on client side computation, carefully constructed contract primitives, and affirmative state commitment. This keeps all Glittr data on-chain and provides a canonical ecosystem state at regular intervals. Contracts are permissionless. When contracts have custody of assets there is no party (or group of parties e.g. in a multisig) which can access them.

Validators do not actually process Glittr Contracts, they merely confirm that the the a contract call's asserted output is consistent with its input. Because of this all Glittr transactions can be verified in constant time, meaning that MEV and gas-related failures are mitigated.

Affirmative Consensus

Glittr transactions split validation responsibilites between Bitcoin miners and Glittr nodes.

We can think of this as analogous to EVM: the inclusion of a transaction in an ETH blocks affirms that it was a valid ETH transaction (e.g. not double spend) but does not take into consideration the validity of the underlying contract call. EVM nodes then process the contracts and update their global state tries. In this system, contract calls provide input and it is simply assumed that all nodes arrive at the same output. There is no affirmative canonical state.

With Glittr, the validity of the Bitcoin transaction is affirmed by the fact that it gets mined. Double spend, BitVM-style bridging, DLCs, and TapTrees are confirmed by the Bitcoin miners directly. The fact that a contract state UTXO cannot be double spent is critical to the security of Glittr, but does not need to be managed by Glittr itself.

Where Glittr is very different from EVM is that it provides affirmative consensus. Glittr contract calls provide both their input and their asserted output. Full Glittr Nodes participate in a Proof-of-Stake consensus protocol and the network makes a commitment to the validity of transactions on a regular interval. Because of this, Glittr does have a canonical contract state - the asserted output of any transaction the network has confirmed as valid. Affirmative state is necessary to facilitate a system that is highly efficient in terms of memory and computation.

State Management

Because Glittr is UTXO-based (as opposed to account based), there is no need to maintain a global state trie. Each Glittr Contract can in some sense be seen as its own state machine, with each transaction providing a state commitment.

While it is expected that Glittr Full Nodes validate all calls to all contracts, it is not necessary to do so in order to validate a call to a specific contract. Lite Nodes, e.g. users and wallets, can (and should) validate their own contract calls.

Some Contracts are stateless, meaning that the validity of a transaction depends only on the contract itself and not on previous transactions. Validating these contracts requires only that a node has access to the Contract instantiation transaction and the transaction in question.

Contracts that are not stateless, e.g. AMM pools, may require some amount of local state construction for validation. Each contract call provides a reference to a previous state commitment (contract call), so transactions can be processed in a serialized capacity. At the end of each consensus cycle (~5 Bitcoin blocks), an affirmative network-level commitment is available for the state of the contract so local state maintenance can build from there.

To prevent intra-block state maintenance from causing issues with dApp functionality, it is recommended that actively administered contracts (e.g. AMM pools) facilitate transactions so that they are correctly inter-referenced.

Permissioned contracts (e.g. vaults, loans) use state commitments for access control as opposed to hard-coding public keys. Because each contract call is a state commitment, in these contracts the user must spend a state commitment (e.g. UTXO which asserts a vault balance) to make a deposit, with the output of this transaction being a new UTXO with a new state commitment. This guarantees that validation remains non-recursive and access remains limited.

Space/Time Efficiency

All Glittr transactions are non-recursive and can be validated in constant time with minimal RAM.

The Glittr SDK provides modular composability for contracts, but it is not a language. Glittr is not Turing-complete, and this is by design. While not all methods in the Glittr SDK (TypeScript) can be computed in constant time, all of them can be verified in constant time (Rust code on Glittr Nodes). The Glittr SDK can in some sense be thought of like the Bitcoin OP Codes but with dramatically more functionality and significantly easier to use.

Stateless transactions require trivial space as only two transactions need to be available in memory. Because Contract instantiations are generally unspendable, a validator should have ready access to these transactions in the Bitcoin UTXO set. (full Glittr nodes must also operate a Bitcoin node)

For contracts that are not stateless, local state constructions is still lightweight. Because Glittr has regular affirmative consensus commitments, this should not exceed ~5 blocks worth of transactions. Even then, it is only necessary to keep the transactions pertinent to the specific contract in memory. Because double spend and other properties are enforced directly by Bitcoin mining, it is further possible to retain only the body of the Glittr transactions themselves. Uncompressed these are about 220 bytes.

Data Availability and Reconstructibility

Glittr has perfect data availability on Bitcoin Layer 1, and the state of any contract is immutably reconstructible from this on-chain data as of the latest consensus commitment. Glittr nodes do not require any off-chain data to validate transactions.

Oracles

Contracts calls rely on off chain data, e.g. a price oracle, include a pre-committed Schnorr signature of whatever off-chain data they wish to represent. Validators need only check that the commitment matches the expected message and public key. Users do not need to trust these oracles, because the signatures are included in the transactions directly. If the user does not agree with the message (e.g. price) the oracle is committing to, they can simply choose not to broadcast the transaction.