STAS protocol — Clearing up the air

Getting your Trinity Audio player ready...

There has been a lot of confusion over the differences in token platforms and continuous mention of some misunderstood notions about what happens to servers when they receive a token which it has not yet seen or indexed, so I thought this would be an excellent time to clear some confusion up, now that STAS (Substantiated Tokens with Actualized Satoshi’s) protocol has been released.

What is the ‘back to genesis’ or ‘back to issuance’ problem?

It is a perceived problem that some people believe will be an issue when a wallet is presented with a token from an issuance which it has not been indexing in the past, and is required to validate its authenticity, so that the receiver can confidently accept the token as legitimate. The issue is not a real problem, but it is misunderstood as such because of the false belief that one needs an ‘oracle’ external to Bitcoin in order to process and receive token transactions. This itself requires further clarification, as the process of sending, receiving and authenticating tokens are separate concerns and have differing requirements and legal treatment.

Why the hate against Oracles?

The avoidance of ‘oracles’ is funny to me. What wallet do you use? HandCash? Their backend server is your oracle. ElectrumSV? Sorry to break it to you, but you are using ElectrumX server as your oracle. There is no way you are USING Bitcoin without some oracle other than the miners if you have a wallet. Use paymail? That’s your oracle. These oracles are just indexers. Indexers listen to all transactions on the blockchain and store and serve a subset of them as a service. Coincidentally these oracles you already use will be exactly the ones that can implement that STAS API protocol. STAS is just a patch that your existing index oracles can add, but app-level oracles is already part of the ecosystem so why the demonization of them all of a sudden? And why do we see more and more blockchain projects start up to ‘fix’ this perceived ‘problem’ with Bitcoin?

Simple: because tech nerds like to be kings of their own fiefdoms. They want to be gods of their own domain. So they will likely launch a new blockchain out of inflated egos and a sense of importance. Simple. Psych101. That’s really all that is behind “Novobitcoin” and “Radiant” projects. Projects whose only reason for existence is to make the blockchain miners be token indexers and oracles instead of delegating this to the token platform service providers.

The term “back to genesis” is also a misnomer. When has a wallet ever needed to trace back to the original coinbase txn every bitcoin it receives to ensure it is not a fake Bitcoin token? (Perhaps coins that were minted out of thin air by miners?) Wallets never need to do ‘back to mint’ validation. That is a problem that was solved with the Bitcoin UTXO system. All you need to check is that the coin you are paying has valid spendable parent coins in the live spendable coin mempool. Any node or indexer keeps an up to date index on the latest set of spendable coins. So ask any one of them. This is the decentralized solution.

On the attempted avoidance of external oracles

Some will say that if it isn’t the mining nodes holding this data, then you may have malicious oracles give you incorrect answers. Miners are prevented from doing so thanks to built in economic disincentives that punish miners which break from the consensus and act dishonestly. But token indexers do not (or do they?). So they want to avoid dependence on external oracles.

It is a futile endeavour. You can stay independent from a token issuer for the purposes of transactions that the issuer has no legal means to prevent. But you can never avoid the issuer when it comes to redemption, or legal protection of your ownership rights to what the token represents. By that reason alone, the issuer or the issuing platform will always have the natural incentive to run and maintain an honest indexing service for the tokens they issue. Others may have the incentive to be able to provide you this service at a per use micropayment cost. If they act dishonestly, they will soon lose all their clients. This is a business where reputation matters.

So there will always be some public service that can be used to authenticate tokens.

So nobody will EVER need to trace ‘back to genesis.’ (Except as a one-off case of when a new index node is bootstrapping up, which is part of downloading the whole blockchain anyway…. which may also be irrelevant in the future if people just sync UTXO sets and NEVER download the blockchain anymore…)

Even in the case of a peer-to-peer txn, the RECEIVER using SPV needs to ‘check with an oracle’ to ensure that your payment is good. In this case, the oracle is a transaction processor. That processor, if smart, will also offer a STAS authentication check API for txns that move STAS tokens. You cannot have a totally oracle-free txn, as you need differing degrees of oracles to verify or finalize things. Miners happen to be public generic oracles for all bitcoin movements, and wallet indexers run by issuers will be oracles for their tokens. I mean, even Paymail servers are an oracle you have to trust.

But critics are quick to point out: “This need for a token oracle/indexer in order to be able to accept a STAS token is an extra burden on 0-confirmation transactions right?”

No. Actually you don’t need to wait for a STAS txn to be mined for it to be verifiably safely or ‘finalized’. This is also why I say that the STAS security model is equivalent to SPV. Once you understand this, you understand why STAS is not a second layer token overlay like the others… instead it is a ‘layer 0’ token protocol on top of Bitcoin. It’s security and scaling model is equivalent to Bitcoin’s. With native Bitcoin, the mining node network provides the following independent services as part of a transaction verification: 

• Transaction sequencing and settlement finality (inclusion in a block)
• Balance checking (ensures that there are enough tokens)
• Authenticity check (ensures that the tokens are authentic)
• Historical record archival (provides historical records on request)

With layer 2 solutions, their proprietary servers/oracles provide all of the aforementioned services for the token system. With STAS, only the function of a token’s authentication is borne as a paid service by indexing servers app-layer over Bitcoin. But that layer is equally as public, permissionless, and open (as much as any wallet service or block explorer indexer is). This is the difference between STAS and layer 2 solutions where the verification is done by proprietary servers, with STAS you get 0-conf transaction finality similar to native Bitcoin SPV, but with layer 2 tokens, you always need to wait for a block confirmation to be sure that of the transaction sequencing and finality. In addition the token balances is something that only the proprietary server keeps. Without that oracle, your wallet will be unable to execute a transaction. Your wallet is just a key. The balance of your tokens lives on their servers.

STAS is scalable as Bitcoin, but at what cost?

There are some tradeoffs that STAS makes to get all these benefits of scalability, however. As STAS is essentially just a special locking script, this locking script increases the size of the transaction an can increase the transaction fees needed to be paid to process it. However, I feel in the long run the scalability guarantees gained by putting all logic in script (and paying miners) is good, while other solutions have traded off the fee increase and just kicked their scaling issues down the road…

If you have a token protocol that needs to do proprietary logic off-chain (or worse, maintain the wallet token balance!) then you have effectively took something that Bitcoin solved (practical, massively parallel, verification) and chose the same burden that Ethereum did; the cross of sequential stateful processing; where keeping a massively distributed global state in sync is going to be your unsurmountable scaling problem.

Now if your potential token holder population is going to be at most <1 million users… (say you want to just replicate a loyalty points program) then this isn’t an issue. But if your token is supposed to be NFTs that last 100 years and everyone on the planet can potentially be a holder, then you certainly want to use STAS with native satoshi as the tokens as it benefits from all the scaling solutions which bitcoin has already solved. These scaling challenges include solving the double-spending problem in a decentralized way, economic based security guaranteed by a system that encourages competition, and its parallel scalability, allowing peer-to-peer transactions to be made locally and only settling on-chain.

STAS is the FIRST token standard worth standardizing… because, unlike the second layer token solutions, who have customized metadata formats, and use bitcoin just as a ‘disk drive,’ STAS is simply a locking script and a STAS issuance ID. There is nothing there that is proprietary and that you need to understand separate from Bitcoin, much like Paymail is simply a text message that points to a server on a DNS entry.

I have written more extensively on this in the STAS white paper, but since this thread will likely be used as a reference to tokens, I’ll summarize the entire STAS protocol here. So people can see why only STAS is worthy of being called a standard, and the rest are just “app layer” token platforms and ‘walled gardens’ in comparison.

Pay to Public-Key-Hash (P2PKH), meet Pay to STAS (P2STAS)!

P2STAS is a locking script that basically says this: Output 1 of the next txn that tries to spend this MUST also be a P2STAS (it is recursive and requires reflection, achieved via OP_PUSH_TX).

Optionally, Output 1 need NOT be a P2STAS locking script IF the address destination is this particular REDEMPTION address. (A constant hardcoded for all tokens of the issuance).

After this script, we end with a OP_RETURN, (note not a FALSE RETURN, but a spendable RETURN) part of the script, which is never executed by miners, thus constitutes pure data attachment. This data attachment includes the STAS token ID and Issuance Txn ID.

And that’s it!

Developers are free to add ADDITIONAL spending conditions on the outputs if they wish. But that doesn’t change anything. The above logic is static, standardizable, and importantly recognizable via RegEx as much as P2PKH is, or OP_PUSH_TX is. When an indexer recognizes as P2STAS, they simply grab the STAS token ID bytes from after the OP_RETURN, and in addition to indexing this UTXO by its txn ID (the standard txn process), it also adds this UTXO ID to the STAS token index for the given token ID. If this is the first time it is seeing this particular STAS token ID, then it creates a new dictionary/map/index for this STAS token ID, and adds the UTXO. That is it. No complex logic. No balance checking, or maintenance. Nothing special besides indexing. Note that this is the same process that any wallet server offers, except instead of a STAS Token ID index, it creates and maintains indexes for user wallet master public keys (xpubs).

That is it. No complex logic. No balance checking or maintenance. Nothing special besides indexing. Note that this is the same process that any wallet server offers, except instead of the STAS Token ID index, it creates and maintains indexes for user wallet master public keys (xPubs).

If a wallet user passes a STAS txn to be authenticated, the server does its regular UTXO/mempool update action, only instead of doing against the whole UTXO set it does it against specific UTXO subset, associated with legit STAS UTXOs. This either returns TRUE if it was updated, or FALSE if the inputs are not in the UTXO subset for that specific STAS token ID, which indicates that the txn is an attempt to pass a forged STAS token by the spender. As a forged STAS token txn still is a valid Bitcoin transaction, the main mempool is still updated by removing the inputs and adding the new outputs. But the specific STAS token subset index is not updated. The token receiver with this authenticity response is free to taken whatever action they wish ranging from ignoring the transaction to reporting the attempt at forgery.

In all cases, STAS gives the following 2 guarantees which many token platforms before it could not: 

1) forged tokens cannot be practically ‘passed off’ as real without relying on a centralized solution

2) tokens accidentally sent to wallets which cannot understand or spend STAS tokens cannot be lost—it just means that the recipient will have to download and use a STAS supporting wallet to move the tokens.

In conclusion, there are plenty of ideas and ‘common wisdom’ misconceptions that surround token platforms in BSV. Most of this is just due to the fact that many different token projects started off trying to address a different specific use case and evolved over time into a platform that is catered to that use case. STAS is the first generic token protocol that can address all token uses cases, given its reliance on native bitcoin script for token transfer conditions and satoshis themselves to keep the balances. By doing so STAS can leverage a lot of the infrastructure which bitcoin has already built out in order to solve things like 0-confirmation transactions and a scalable solution to the double-spend problem.

The trade-offs for this flexibility and scalability is/are mainly twofold:

1. Increase in per txn fees, due to the increased size of each transaction with all the conditional logic represented natively on bitcoin.
2. The need to unroll all your loops as bitcoin script does not allow for dynamic looping, and you will have to have all the number of loops in your smart contract logic be pre-determined. This is practically represented by the fact that you need to have a fixed number of inputs and outputs in each transaction.

Given these trade-offs, for complex logic that allows for more conventional ways of programming, a layer-2 token solution may suit better. (Such as Run, which uses Javascript).

The legal fine print

One final aspect which isn’t much discussed but is equally as important is how the law sees and treats these different token systems. It has taken a quite a while for legal treatment of digital currencies to mature enough to the point where some court precedents have been set. Tokens on top of blockchains themselves have the extra complication that each case must be examined specifically, given that the treatment of a loyalty point token application would be fundamentally different from a digital cash token issued by a bank.

In this regard, the notable difference between STAS, which does not require a third party server which holds client balances to be part of the token system and layer 2 solutions, is the benefit that the issuers need not have to be licensed as payment processors, or depository businesses. This stems from the fact that the only service that a STAS transaction requires is an authenticity check which may or may not be provided by the issuer themselves (though in many cases would be). There is no external requirement for a wallet to create, sign, send, or receive a STAS token (this is exactly like Bitcoin). If they simply trust each other, then the receiver can do away with the authenticity check. There is no external balance that needs to be kept on an official ledger. Each wallet holds it’s own ledger and record of the tokens that it controls.

This is markedly different from layer 2 solutions, where their server is an integral part of the system, and required in order to create and process transactions of the token. For those familiar with the e-money laws in Japan, it is similar to the difference between IC card tokens, and server-based token systems, such as the SUICA system. The former has the tokens stored on the card IC itself, where loss of the card means permanent loss of the tokens, while the latter the card is just a signing key for a balance account which is run on the issuers system (Japan Rail). This legal requirement may be a deciding factor in some jurisdictions where acquiring such licenses are prohibitively expensive. One such company which has done the necessary research into this angle is Centi.

So there you have it, the run down of the pros and cons of layer 2 token systems vs STAS. Currently as it stands, I believe the biggest downside of STAS is the lack of tools for developers and the fact that if you wanted to program smart contracts in STAS, you will have to learn how to write Bitcoin Script. This is not an easy ask, but I expect in time tools will be built to make the developer experience nicer.

Be that as it may, it is my opinion that the trade-offs is one that is well worth the costs, especially when the application needs global scalability and reach as the Bitcoin protocol itself.

/Jerry Chan
WallStreetTechnologist

*thanks to Stas Trock for contributions to this article