Creating Tokens on Bitcoin(BTC) using OP_Return, Smart Contract Treasuries and Distributed Bots Secured by Digital Rights management


Hi, r /bitcoin, I'd like to share with you a concept I created for designing web finance systems that function on Bitcoin Layer 1. Hope you like it :)


Before explaining anything else, I must explain motivation: Bitcoin is by and large the most decentralized crypto currency in existence, however it does come with some downsides;

  1. Fees
  2. Block time


Though various upgrades to the Bitcoin network have allowed transaction fees to come down from their all time high of $62 in March of 2021, they currently sit at an average of $0.62. fees are calculated in BTC, this means if you have a fee of 0.000031 BTC ($0.62) @ $21,100 and the BTC to USD price should go up to $42,200‬, then you end up with fees that cost $1.24, and so on as the coin rises in value. But note that even now (Jan 16 2023) it is still commonplace to get transaction fees between $4 and $15.

Block time

All transactions are processed in blocks, each block can hold 2MB of information, each transaction is around 200-400bytes, each block can hold around 2000 - 19000 transactions. All blocks are processed in 10 minutes, this is a time limit created as part of the consensus mechanism.

Miners must compete for the right to hash a block, they do this by completing a complex mathematical problem, the first to complete it wins the block and the rewards for doing so. This just means your transaction cannot be processed in anything less than 10 minutes, but could take anything between 30 minutes or 3 hours as transactions begin to backlog.

The Forks

With this is in mind many projects have set out to find solutions towards bringing down the fees, some called for changes to the code which would allow bigger blocks and therefore more transactions and also reducing the block time of 10 minutes. But this is not a solution, making such changes would greatly reduce block rewards while making it harder for small miners to win rewards.

It would also be very expensive to run a node and validate past transactions due to the bandwidth usage. This question of code changes resulted in what is now called "the fork wars" in which some miners split away to create their own versions of Bitcoin.

The block size was eventually increased from 1MB to 2MB and incorporated Segregated Witness (which stores the "witness" of each transaction separately from the amounts [inputs] and destinations [outputs].

This fork greatly helped to alleviate some burden on each block as more transactions could be stored with less space. Legacy transaction formats from the old version of Bitcoin can still be used, as all forks of Bitcoin are backwards compatible.

Layer 2's

Other projects wanted to approach this problem differently and believed transactions needed to be moved to a second layer or in other words; using a different blockchain that is connected to Bitcoin in some shape or form. The pinnacle of this is the Lightning Network, which in simple terms; opens a channel on both layers, users deposit into a smart contract on layer 1 and their funds are reflected in the node's ledger, the user can then freely send Lightning BTC to anyone for very low fees almost instantly, the final balance (UTXO) of every transaction is then reflected on the Bitcoin blockchain, this is why Lightning is the best layer 2 because it is designed to achieve finality on the Bitcoin Blockchain.

As novel and good as the lighting is it still suffers from some issues;

  1. Channels need to be opened on the blockchain, this costs an estimated $25 to $60, this incentivizes node operators to keep their channel open longer than they should.
  2. Nodes need to run a full or partial copy of the Bitcoin blockchain history, this allows them to validate the transactions they are doing on both layers. But comes with added costs to the node operator.
  3. Each channel is limited by how much liquidity the node possesses, on average nodes have around 500 channels and 50BTC liquidity, most transactions above 0.0096 ($200) simply cannot go through.
  4. When users need to send funds to one another but find themselves on different channels, those channels will have to be connected, this creates an issue when the channel needs to be closed to reflect the funds on the main blockchain, because it has to be a bilateral closing, one side can decide not to close their channel due to the cost of doing so, or by malicious intent. This results in a situation where most channels are left open indefinitely.

Wrapped Tokens

The other form of Layer 2's are wrapped tokens, wrapped tokens are supposed to be 1:1 Bitcoin copies that exist on Smart contract Virtual machine blockchains (this means they store their smart contract code directly on the virtual machines and not in an address key, this allows more information and complexity but increases burden on the nodes).

How this works is that the user deposits their real BTC into a contract, the controller of that contract then does some computations and communicates with the Layer 2, there-by issuing new tokens on the other side and calculating who owns them based on who deposited and the destination they set.

Some of these include; Stacks, Liquid Network, Rootstock, Sovryn, etc.

The problems with these systems are;

  1. The system communicating with the two chains is a centralized computer, meaning it can be exploited to drain all the funds waiting to be bridged
  2. The price of the wrapped version of BTC on the layer 2 uses liquidity pairing and constant market algorithm. This means it is paired with something else like BTC/OTHER, the amount of each token in the pair determines the price of the other based on their relative scarcity. The problem then arises with price calculation, price is calculated by; total number of holders vs total circulating supply vs liquidity amount. This means each transfer is recorded the same as a purchase, if someone sends huge amounts of the token to a huge number of addresses it will cause the wrapped Bitcoin price to increase significantly and depeg from the real Bitcoin price, leading to a situation where users can redeem more of one or the other due to the price difference.
  3. Bridging is computationally difficult and takes time, each transaction requires no less than 6 confirmations, but transactions are confirmed in massive batches which won't be accepted into a block for many hours, this batch scheme is meant to reduce cost rather than sending each transaction individually.

Non-Scaling Token Mechanisms

That aside, not all Bitcoin applications and systems are intended to scale the network, there has been no shortage of attempts to create token systems on Bitcoin, the most notable of these are RGB Iris and Colored Coins.

RGB Iris; is a client-side scripting application that encodes user specific information into each Bitcoin transaction, this is not a scaling solution in itself but a way for users to create tokenized assets within each transaction.

Colored Coins; is a similar scripting application but uses OP_Return, an op code for Bitcoin which allows a user to send custom messages in the output of their transaction but direct it to either a non-existent address or as part of their regular transaction. The messages in these transactions are the details of a tokenized asset.

The explorer for these systems is what validates each transaction's format.

Both of these are still subject to the fees and block time of the main blockchain. Due to the way they are issued; they cost more than a regular transaction and could take longer since they might not fit in some blocks.

HYPR Protocol's Solution

To solve the issues faced by Bitcoin's scaling solutions, HYPR Protocol has been made with the aforementioned issues in mind.

The system described in this post is called "HYPR" (placeholder name). This post outlines how Fungible and non-fungible tokens can be created and managed on Bitcoin while preserving the security of its users. This would allow the creation of secure stable currencies using the trustless TeF algorithm (not an external data source). With non-fungible tokens it will be possible to create subscriptions, reoccurring payments, on-chain escrows and trust funds.

HYPR is designed in such a way that it would be impossible to "hack" a token or have special privileges that would allow mismanagement to occur.

The system is purely in its design phase. HYPR is open source; Apache 2.0, Digital rights management is only used to secure post-genesis versions of node software.

  1. OP_Return
  2. Smart Contract Treasuries
  3. Distributed bots


An "OP_Return" is a message in a transaction output as seen in the example above, OP_Return is used to create a new "account" within the distributed HYPR Network, the bots read all associated OP_Return transactions sent to the HYPR multi-sig address and use that as an account list.

In the above example we can see a line for "variables", the variables are an "internal ledger" or json directory stored within the distributed bots that hold the user's actual balance.

So what the user does when they need to deposit for the first time is interact with the web app, which will request a digital signature to prove that they own an account, this signature plus the randomly generated code issued for encryption is stored on the OP_Return itself.

The user would then need to send the required fee to create the OP_Return to an address controlled by the distributed bots. While also sending the desired amount for deposit to the treasury multi-sig, the transaction is expected, so even before it is confirmed on the blockchain the bots will update the user's balance in the internal ledger and the user can begin transferring to other accounts, but each deposit from an unconfirmed transaction is tainted in an "error chain", this means if the transaction is rejected or reverted; every subsequent transaction logged can be undone and redone without the tainted coins.

When a user has created their account they do not need to pay a fee to create a new OP_Return message and can deposit freely, this is because the OP_Return stores a static account and does not need a new message on-chain to update balances, balances are updated from within the internal ledger.


Each transaction requires a proof, this shows that the user in question owns the address they want to transact with and is achieved through the use of digital signatures as seen above. The user is issued a code which they need to sign in their wallet, they present the output and it is corroborated with the public key and original code, this proves they are the rightful owner of the address.

The proof for each account creation is appended on the OP_Return, and the proof for each transaction is appended to the json file within the bot (only the last 10 transactions for any account is logged, each transaction is sorted by "nonce" or number once, a simple way to count each transaction). Every internal transaction is public and auditable.

Smart contract treasuries

On Bitcoin(BTC) it is already possible to create smart contracts that obey simple parameters or rules, for example a user could create a contract that will send a specific amount of BTC to a specific address after a specific number of blocks have passed. How HYPR incorporates this is that all funds are held within a "Treasury contract", this is a multi-sig address, which means six keys are required to pass a transaction, each of these keys represents a bot sub-group in the distributed network.

To expand on this; bots within the network are assigned sub-groups, each sub-group possesses a key which is created automatically post-genesis, meaning no one sees the keys before they are generated, the security of this is guaranteed in the heading further down; "distributed bots".

Tokens on HYPR are similar to accounts, their creation is made on an OP_return and their variables are stored within the internal ledger, multiple types of token updates exist, in the above image we see the most common which is a token_buy, when a token is bought two updates occur; one for the user and one for the token account, this sends a certain amount of coin to the token's account while sending a certain amount of the token to the user's account.

Each user can only hold (4) tokens at a time, when a user buys a token for the first time what this does is add their public key to a token registry and the slot used to hold said token, this slot is then used for all future buys of the same token. The mechanism for this swap is single sided and not constant market, single sided means an enforced amount of token is swapped for a specific amount of coin, the impact of each buy is then recorded and used to update the price.

This means liquidity is not a pair, the liquidity for each asset is stored separately, ensuring that even if liquidity for one asset should drop significantly so long as there is enough for a particular trade it will enforce the correct price.

The use of this system to create stable currencies would use a static price in TeF, TeF is simply a data source gotten from the 30day average transactions per block, logarithmic, on the main blockchain divided by 100,000,000, and inverted, this becomes 1TeF.

As seen in the chart above, average transactions moves up and down with price, just not at the same rate, sometimes it dumps harder but corrects this by dumping less on subsequent Bitcoin price falls. This is because TeF is representative of the commodities market and currencies as a whole and not one currency. But is still correlational to the dollar price. I ran a pearson correlational analysis on data for Bitcoin Transactions 30day average logarithmic vs Bitcoin price 30day average logarithmic, from 16-jan-2021 to 16-nov-2021. the result was R = 0.5763 P = 0.3321, any "R" value above 0.5 is considered correlational, any P value below 0.05 could not have occurred by chance, this means there’s only a 33% probability that the data was accidental, full data of the analysis can be found on my medium.

Tokens pegged to TeF using the existing swap protocol will always trade at the exact TeF price.

Distributed bots

The HYPR webapp and everything else managed by the network would be hosted by distributed bots, anyone can host a bot and receive rewards per transaction, transactions are randomly assigned to nodes in the network and make use of "absolute consensus".

This is possible thanks to the network's Digital rights management software known as Green HYPR, Green HYPR prevents reading or writing of the node software by anyone but itself, it does this by embedding itself in the kernel and seizing control of the computer. When the computer is booted up, Green HYPR boots with it and runs a simple taskbar launcher which can be used to start or stop the bot.

Further details and protective measures for Green HYPR are explained on my Medium.

How this is an improvement over token swaps on Smart Contract Virtual Machine chains (SCVM)

A. Swap protocols on SCVM chains typically use a constant market algorithm, this means the assets are paired and go up or down in value depending on which asset is more scarce. I.e. if you have BTC/OTHER with 5000BTC and 5000OTHER then they are both equal in value but if one should become less, then the scarcer one is more valuable.

The problem arises in how price is calculated; total holders vs circulating amount vs liquidity, each buy is a transfer, each transfer is also a buy, each time a token is transferred it is recorded as purchase, this means if someone were to distribute the token's supply to a large number of addresses this would greatly increase the price of the token. However, because those were not actual purchases; liquidity was not added, so there is a liquidity deficit. The image below illustrates that but in an extreme example;

The SCVM fungible token shown above was distributed to millions of addresses, thus its circulating supply and number of holders made it seem more valuable than it actually was, this exploit can and has been used to "game" the constant market system. HYPR solves this.

B. Users cannot pull liquidity; this is because liquidity on HYPR is a network primitive and not a token standard that can be customized, When users create a token its supply is not active until adequate liquidity is reached; this is; preset supply of the token multiplied by the preset price. Once liquidity is added; the deployer still has to buy the token same as everyone else.

The incentive for creating a token are the fees taken on each transaction which cannot exceed 5%, though fees are only paid out once liquidity is above 105% of the price multiplied by supply, each fee below that is instead used to refill the liquidity pool.

C. Users cannot define special privileges on the HYPR Main-network, this means a user cannot "hack" a token using a backdoor, because there is no backdoor. However because it would be possible to create sub-networks using HYPR multi-sigs that can in turn have their own internal ledger, it would be possible for someone to create a webapp where there are backdoors that allow mismanagement and fraud, but the user would have to be lured to such a site in the first place, sub-networks are not shown on the main-network in any fashion.


In the span of this post we have seen some problems facing Bitcoin and how solutions were devised, we also saw the shortcomings of those solutions and how HYPR solves all of that. Here are a few points;

  • Deposits to HYPR are instant
  • TeF allows stable currencies that don't depend on an external data source
  • HYPR's Swap protocol prevents price manipulation
  • HYPR can scale infinitely as new nodes join the network
  • HYPR is not limited by the liquidity inside it, all Real Bitcoin is reflected 1:1 upon deposit
  • Green HYRP prevents any and all tampering of node software and does not make use of encryption

With that said I will conclude the post here, thank you for reading, if you have any critique or recommendations please let me know below.