Token protocols on BSV: Sigil Token

In the next article of our series of interviews with token protocol founders on BSV, we interview Dean Little, CEO of Bitping and creator of the Sigil protocol.

What can the Sigil protocol provide that no other token protocol can?

Dean Little: Sigil is the most cost-effective, scalable means of handling arbitrary token logic with a minimal on-chain footprint. It’s like having the simplicity of building on RUN, with the inbuilt double spend protection of sCrypt tokens, but without needing to be a script wizard or spend thousands of dollars on expensive cloud services to index transactions. It does so by adopting the following paradigms: 

  1. A coin is a chain of digital signatures. Without verifiable signatures from known public keys, there is no easy way to verify the validity of a Bitcoin token at a glance.

  2. In almost all cases, a token is only as good as its issuer, and thus an issuer’s signature may be deemed as good as valid, hence the name “Sigil”.

  3. By requiring both the user and the issuer to sign for something, we can ensure that spends are conducted in a BIP270-compatible manner, enabling us to combine the execution of a contract and the indexing of its subsequent utxos into a single process, meaning we will never need to scan the blockchain.

What motivated you to develop the Sigil protocol?

Dean Little: I found myself having some fundamental issues with the approaches taken by current solutions available on the marketplace when it comes to tokens on BSV. Consider the following:

On Bitcoin however, it is typically quite complicated to spend tokens or execute contracts. Wallets typically need to implement some kind of token SDK and index each individual UTXO they want to spend. When you force wallets to be the ones to do this, you are actually asking them to pay out of pocket for some expensive cloud provider to index some kind of script that they don’t necessarily know the layout of, and then subsequently know how to unlock it, including correctly calculating change, formatting token outputs, and preventing over/underflow events. I think these actions should primarily be the responsibility of the token issuer, not the wallet.

On account-based blockchains like Ethereum, executing contracts and moving tokens around is much simpler. All wallets need to do is hold a private key. The wallet is provided an ABI to call an action against, with all the data pre-populated by the app they are interfacing with. They then give explicit consent for that action to occur within their wallet, sign the inputs of the transaction and hand it off to the smart contract to determine the outputs for them. In my opinion, this is the correct model, and Sigil makes it possible on Bitcoin.

Twetch was the first to implement Sigil with their Hat launch, then Canonic followed shortly thereafter for their NFT market, can you highlight why they decided to adopt Sigil vs. implementing an existing protocol?

Dean Little: The biggest selling point for Twetch was the ability to use Bitcoin to prevent double spends, whilst also having something that’s cheap to run and easy to work with. It is a very good thing they went with a UTXO-based solution too, as their server got absolutely annihilated with purchase requests upon launch, however the beauty of using Bitcoin to handle this problem is that each UTXO can only be spent once which is definitely what you want when dealing with such unprecedented demand.

The choice to have implementers co-sign (via use of multi-signature transactions) certainly solves the scalability issue that other token protocols face, does the Sigil protocol require all implementations to co-sign on each transaction? 

Dean Little: You could certainly go ahead and remove that constraint, but doing so means you have to run a blockchain listener to index spends, as it allows users to not conform to BIP270. For some applications, this is a good idea. I think these things will inevitably improve over time and become more flexible. For now, I’m happy with that choice, as it puts the onus on the issuer to provide service to the customer as opposed to externalising that responsibility to the wallet.

What are you most excited to see built with Sigil?

Dean Little: Blind auctions, revenue share tokens and “DeFi” (let’s be real, DeFi isn’t actually decentralised) stuff would all be cool. The great thing about using Sigil is it makes use of different SIGHASH functions, enabling this kind of advanced signing logic to do things like hold an auction where UTXOs of bids are temporarily frozen and only one person can possibly win because the final sale transaction has an atomic outcome. This is much nicer compared to the current custodial model of using SIGHASH_ALL, taking people’s money and then refunding it.

Will the Sigil protocol be documented for other application developers to build atop of?

Dean Little: Yes. Licenses are available for purchase. Message @40 or @1 on Twetch.

Token protocols

Can you give your thoughts on the ‘Layer’ labels for Tokens? (ex. STAS as L0, sCrypt as L1 and Tokenized as L2)

Dean Little: Layers are a flawed paradigm. Piggybacking off of an existing token or using an esoteric Forth clone does not automatically make something better. Some problems are best solved by script. Most aren’t. I expect that might change over time though. In my opinion, the most important feature of Bitcoin is the ability to solve the double spend problem. So long as you use it for that, I think you’ve already unlocked its most important superpower for your business.

What are your thoughts on using satoshis for tokens?

Dean Little: This appears to be a hot topic. Readers may have noticed that I recently forked the BSV node software to remove the restrictions on offering dust and 0-sat outputs via JSON RPC. 0-sat outputs are very interesting as they solve a lot of problems with nothing but proof of work, do not have the same divisibility issues as satoshi tokens, and losing keys doesn’t result in a decline in the supply of satoshis.

I am quite bullish on this as a long-term solution. That said, at the end of the day, what the market ultimately demands is flexibility. While I may advocate for a certain position, I ultimately believe that people should use whatever solves their problems in the most cost-effective manner. I would be just as skeptical of any solution that locks me into having to use satoshis as one that locks me out of using them.

Do you think multiple Token protocols atop BSV can exist?

Dean Little: For now? Yes. In the long-term? Not sure, but probably.

If so, why?

Dean Little: There are multiple token standards on most other blockchains. In the short term, I think it’s as simple as different use cases having different requirements and nothing being mature yet. Some people want to create unregistered securities because their jurisdiction is unregulated. Some want to make something rigidly compliant to some esoteric standards pushed by some bureaucrats. Perhaps some don’t even care if their token is double spent, or even spendable. Some want to create a CBDC. Some want to create privacy coins. Some of these use cases are better served by one protocol or another, and that’s a good thing.

We will obviously need to see how this plays out long-term. It is my opinion that all smart contracts on all blockchains will eventually go the way of WASM, which could play rather nicely into the Sigil protocol as it allows parallel execution in the browser and the server, so you can just piggyback off of things like hashing, merklisation and ECDSA for verifiable execution. At the same time, I also think that there will always be some level of demand for solving problems in native Bitcoin script. Over time, we will get a clearer picture of how this will turn out.

How is that different than claiming multiple crypto currencies can co-exist?

Dean Little: It’s not dissimilar. Multiple cryptocurrencies can exist. You’d be hard pressed to name a market outside of government-enforced monopolies that don’t have both a market leader (Windows, Android, Intel, Amazon, PayPal) and a main contender who keeps them on their heels (OSX, iPhone, AMD, eBay, Stripe).

Ethereum

How can BSV out-compete Ethereum?

Dean Little: For better or worse, Ethereum has been the powerhouse of economic activity in the crypto space over the past few years. With that said, I think you can see that it is currently stuck in a stalemate between high fees and a long wait for solutions.

As such, it is being outcompeted by other chains that are moving a lot faster. The standout example for me is Solana. In just 9 months, they created a node that uses GPU validation to process 57,000 txps on a single node with fees at ~20% the going rate on BSV and a 1MB transaction size, which is what miners will typically allow you to send publicly on BSV.

To be a competitive solution, BSV needs to win on all of these metrics and more. It needs to drastically improve the developer experience, attract better talent, create more incentives for competitive miners to join the network and entice external investors with a chance to cash in on its success.

How can BSV profit from cooperating with ETH and DeFi?

Dean Little: BSV when doing things the Bitcoin way is far from developer-friendly, and the more developer-friendly chains like ETH suffer from high fees due to congestion. There is obviously a double market gap there and a huge opportunity to funnel liquidity from these congested chains like ETH into BSV if we can just make the tooling work in a more familiar way for those devs. 

General

What impact do you think the LAW narrative has had on BSV with respect to tokenization?

Dean Little: Law is supposedly there to protect consumers from fraud and to stop money laundering. As far as I can tell however, what it actually accomplishes is a complete erosion of free trade, property rights, and consumers’ right to privacy.

There are currently millions of identities for sale on the dark web right now that have been hacked or sold from KYC providers due to government mandates. These are often purchased by the very people those laws are supposed to be stopping. Securities law has also placed governments, a class of organisation whose sole specialty is financial mismanagement, as the sole arbiter of what is or isn’t a legitimate asset.

I think it’s a completely bogus idea that has been undeniably harmful. I’m all for punishing actual fraud, but I personally think we should all be advocating for more lax legislation and better financial education in this young and burgeoning market.

If you could wave a magic wand and change something about the BSV culture or business environment, what would it be?

Dean Little: I wish we could stop wasting so much energy on PR stunts, frivolous lawsuits, the cult of Satoshi and top-down planning. If you read what Satoshi actually wanted all those years ago, it was for the technology to stand on its own merits, which in turn attracted many great minds who made it the great success story it once was.

In my opinion, this is the biggest part of the original Bitcoin that we are yet to restore.

Thank you, Dean, for taking the time to answer my questions. I hope the readers learned more about the Sigil token protocol. Please be on the lookout for the next interview in this series.

This article was lightly edited for grammatical and clarity purposes.

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]