sziller.eu - Szilard Gabor LADANYI - 2024

Gold backed digital Asset

Scope of this document - TLDR

This chapter discusses the technical solution of the realization of a Gold backed digital Asset, built over Bitcoin:

  • We discuss ways to:
    1.) issue; 2.) track; 3.) audit; 4.) transact and 5.) burn.
    a self-controlled and centralized Asset, implemented on top of Bitcoin. This asset might be backed with real-world goods - such as precious metals - this however is not discused in this excercize.
    The system is trust-minimized. The user/client has to place some trust in the issuer, can however anytime - on their own - VERIFY if the issuer is acting honestly!

  • We also highlight the differences between the Asset being fungible or non-fungible. Based on legal and/or technical and/or storage details, fungibility has to be considered carefully.

We neither discuss:

  1. the reason behind nor

  2. the real world solution of

storing and assigning Gold to the digital Asset. We simply consider these two issues to be well-researched and solved.

You can skip the BS and jump to the Example

Technology

Taproot Assets
LightningLabs has a production-ready protocol to assign custom-made digital assets to Bitcoin UTXO-s using the 2021 soft-fork called Taproot, in order to inscribe Taproot data into a Bitcoin UTXO. Taproot-Assets - as the technology is called - aims to leverage Bitcoin AND the Lightning Network to transact: 3rd party, centrally controlled assets - such as USD stablecoins or commodity-backed digital assets. The on-chain transfer module is Live and production ready, the module to interact with Lightning is comming soon.

With Taproot-Assets we can issue a digital asset:

  • whoes entire stock is verifyable with Zero-Knowledge-Proof model,

  • where we can issue or burn Assets by ourselves,

  • where we can - but do not necessarly have to - build a StockExchange to watch over trading,

  • where assets are tracked in an off-chain Sparse Merkle Sum tree, granting:

    • fully transparent auditing

    • tamper-evident double-spend proofness

    • minimal on-chain footprint

    • scaleable, client based verification

TA uses Merkle-sum Sparse Merkle Trees - or MSSMT. Do not let the tech-jibberish fool you. It sounds more complicated, than it is in reality. The MSSMT solves the following:

  • as all trees, the Root lets you verify the content

  • it can prove NON existence of data

  • it can prove the sum of funds in it did not change

Law

The EU issued MICA. It takes effect on the 30th of June. Classification of the product may depend on technical details of the implementation of the digital product. It may also depend on if and how the commodity backing of the asset is realized.

Process

We have a well-designed site for the user to buy an Asset representing real-life goods, we store. Heres our example.

1. issuance

Running a tapd client the Admin server can create a Merkle-sum Sparse Merkle Tree - or MSSMT. In this tree the admin creates the amount of funds he/she wants to issue. Admin keeps the Database in the usual centralized manner, but publishes the ROOT of the MSSMT on chain in a Taproot locking script.

Important

Important to distinguish if data is being stored as Tamper Proof or Tamper Evident. The Tree itself is NOT Tamper-Proof: as it will not be part of the Blockchain. Its Root is though, rendering the MSSMT itself Tamper evident.

We issued a set of Assets on our own. We have it all in our DB, and we can transact is, once the DB is introduced to the other party. The DB, which we cannot modify without our clients noticing changes.

2. tracking

Your client has multiple choices how he/she wants to track their funds. The actual Data is stored in Databases across Nodes, involved in the G-Coin Pocket Universe. As data hashes are their own addresses on the tree, finding ones data in the tree is trivial. Thus, your user can:

  • run a dedicated Node

  • ask any of the dedicated Nodes

  • ask the Nodes of ths Issuer

  • take a look into his/her Wallet on online Dashboard, keeping track of their G-Coins.

We’ve seen and followed assets moving off-chain.

3. auditing + validation

Thanks to the Root of the MSSMT being inscribed onchain, using the old MerkleTree validation trick, the user can anytime check if the DB version handed to them is a valid on up-to-date one. Validation serves two purposes:

  • checking the total sum of G-Coins across the DB not having been tampered with

  • validating if all the desired transaction moved G-Coins to new addresses
    (while also cheching if old funds were destroyed in the process)

We’ve validated that DB-s are in consensus. We also validated the size of the total stock did not change.

4. transacting

Nodes keep their DB-s locally controlled. They can update their state according to what they know to be true, based on transaction data. And only need to verify data integrity. Stopnig double-spend is also achieved by the Bitcoin TX itself. It does not sound important at this stage, but as TaprootAssets hit Lightning, Nodes do not need to sync the DB-s, but can come to a conclusion locally and even skip verication as Lightning grants double-spend proofness.

We moved assets inside our system, while using Bitcoin to stop double-spending.

5. burning

As far as I understand the protocoll, the Issuer can Burn Assets as well. This is highly important as it enables timed contracts, to be ceased - once they’ve run their course. A feature not possible with Bitcoin alone, as Bitcoin Transactions do NOT expire. TaprootAsset issued tokens can. The Issuer can burn them.

We’ve shown, assets can have limited life-span.

Example

At this stage I’ve built a small token shop, where you can purchase Precious Metal backed products. The issuer promisses to BACK these Assets with real PM. The customer can pay with whatever currency is agreed upon (in my case it is Bitcoin over Lightning). Once paied for the Assets appear in the Users Wallet and/or on the Dashboard on the Issuers Homepage.

Point of Sale

This is a normal BTCPay server featuring different Assets.

Vault 01
1. Point of sale

In this example the customer pays with Bitcoin over the Lightning Network. You can encurage returning customers to open direct channels towards your shop, to get additional benefit from having remote liquidity.

Vault 03
2. Lightning paments enabled

Sallet Visor Intro page

VISOR Intro
3. using Sallet-Visor necessary modules

Once use-case is clear and well-designed, all features can be integrated into Sallet. This is a modular, customizable Desktop and/or Android wallet designed to house necessary functions only.

Sallet Visor G-Coin page

VISOR Nft
4. tracking users Assets

Beside the normal Bitcoin Wallet functionality we can integrate G-Coin management, and communication to G-Coin Nodes.

Fungibility

Based on the legal environment you might consider making Tokens Non-fungible ro Fungible. Having them Non-fungible makes a slight difference in the code, but a huge one in the real life implementation of the backing, namely:

  • If fungible: the Issuer promises to hand out/ ship only the agreed upon amount of Gold (underlying commodity) to the customer upon presenting the token. Fungibility would refer to that of the real life underlying good itself: GOLD. This would however make transacting with the digital asset more flexible, as users could easily trade them among themselves.

  • Non-fungible: the Issuer promises to hand out/ ship a recognizable piece of good (bar with a specific serial number, a specific goldcoin or even another kind of collectible item). The Issuer would have to store these specific items. Insurance might be a bigger issue as well. Also, the secondary market is way more limited, as there is another layer of trust build into the re-selling transaction.
    At the same time it is more controllable and the European MICA regulation would not necessarly apply.

Back to the top: G-Coin