Tokenized App Demo: Technical Details

CoinGeek Conference Live (2020)

Published in

Tokenized Blog

8 min readOct 7, 2020

A sneak peek of the soon-to-be-released desktop app.

During James’ presentation at the CoinGeek Conference Live 2020, he showed a sneak peek of the Tokenized platform. It was short and sweet, but there was actually a lot going on behind the scenes that I would like to provide some insight into.

To sum up the demonstration, James drafted and formed a smart contract that issued some tokenized assets — coupons in this case. He then exchanged those newly issued coupons for some tokenized pounds in an on-chain atomic swap with Scott, our Backend Lead Developer. What follows is a step-by-step account of all of the technical actions and events of the demonstration.

If you are interested, you can view the presentation and demonstration in the video below. There is also an interesting panel right after that discusses the different token protocols currently available on Bitcoin SV.

CoinGeek Conference LIVE 2020 : James Belding’s Presentation

Contract Formation

James first created a new contract by simply filling in some of the contract editor fields with sample data and clicking a button to sign and execute. This actually involved several operations on the back-end.

Fetch the contract address from the contract operator, off-chain.
Create the contract offer action.
Request a signature from the contract operator, off-chain.
Request a signature from the user, through the app.
Broadcast the transaction to the BSV network and wait for a response from the smart contract agent, which is the on-chain formation of the contract.

The contract address retrieved from the contract operator was 138nAmbmvAzgV8FpXukpnPEX2nznfoafas. You can see all of the activity related to it on-chain.

The contract offer is signed by a key publicly known via the contract operators on-chain contract formation. This is optional, but ensures the identity of the operator is verified and trusted.

The initiating contract offer is in this transaction. The parsed offer data from the OP_RETURN output looks like this.

The first input is the issuer and the second is the contract operator.

The contract formation response (approval of the contract by the agent) is in this transaction. Its parsed formation data from the OP_RETURN output looks like this.

You can see that the smart contract agent added a few fields that it controls.

Asset Creation

James also added assets to the contract by entering their names and a few details. The below actions all happened immediately after the contract was formed.

Create the asset definition actions.
Request a signature from the user, through the app.
Broadcast to the BSV network and wait for the response from the smart contract agent, which represents the on-chain creation of the assets.

I don’t want to make this too long so I will just post one of the asset creations (approval of the asset by the agent). This transaction is the asset creation, which has the asset payload embedded. The format of the asset payload is specified by the AssetType field.

This is the decoded asset payload.

Exchange Tokens

After the coupon assets were created, James formed a token exchange offer to send to Scott. Once James approved the request, the offer was sent on-chain.

Create Offer

James forms an offer to exchange coupons for pounds with Scott.

Create an incomplete transaction request for a specified amount of pounds to receive, and a specified amount of coupons to send in return. It is incomplete because it doesn’t include recipient outputs for the coupons, sender inputs for the pounds, or any signatures for that matter.
Since the requested currency tokens are managed by a smart contract that requires transfer recipients are approved by an identity oracle (just for this demo), James includes a certificate (signed message) from the specified oracle (obtained off-chain) attesting to the eligibility of his receiving address.
Wrap the request in an offer transaction for review. After the inputs are signed by James with the app, it is sent to Scott by broadcasting to the BSV network.

Here is the exchange offer transaction. It contains an output with a Tokenized Message that decodes to this.

The MessageCode of 1001 means the MessagePayload is an Offer type. It decodes to this.

The payload of the above message is a serialized Bitcoin transaction that needs inputs and outputs added to be valid. For brevity, I won’t decode the entire thing. It goes a few more levels deep :-). The completed version can be viewed below. It contains a Tokenized Transfer action sending coupon tokens out from James’ addresses and receiving pound sterling tokens into James’ addresses.

Accept Offer

Scott receives and approves the exchange offer.

Unwrap request from the offer transaction.
Complete the request transaction by adding inputs for the pounds to send and outputs for the coupons to receive. Since there is no identity oracle requirement for the coupons, Scott’s outputs are automatically valid.
Now with all necessary inputs and outputs, Scott’s inputs are signed with the app. Now the transaction is only missing James’ signatures.
Wrap the transaction in a signature request for review. After inputs are signed by Scott with the app, it is sent to James by broadcasting to the BSV network.

Here is the signature request transaction. It contains an output with a Tokenized Message that decodes to this.

The payload is of type 1002, which means it is a signature request. It decodes based on the 1002 MessageCode to this.

The payload of the above message is a serialized Bitcoin transaction. For brevity, I won’t decode the entire thing. It goes a few more levels deep :-). The completed version is below. It contains a Tokenized Transfer action that exchanges the two tokens between James’ and Scott’s Bitcoin addresses.

Complete Offer

James must still add his signature. He was previously able to add inputs and outputs, but could not sign the inputs until Scott had added his inputs and outputs.

Unwrap the request from the signature request transaction.
Sign all of James’ inputs with the app then broadcast to the BSV network.

The resulting complete Tokenized Transfer request is in this transaction. The transfer request decodes to the following. You can see that the required identity oracle approval of James’ receiver addresses is included for the currency transfer.

Currency Smart Contract Agent Receives Transfer Request

The smart contract agent for pounds sterling currency tokens receives the transfer request on-chain and responds.

Verify that Scott has the required currency tokens to transfer and that the included identity oracle signature for James’ receiving output is valid.
Create settlement data for the pounds transfer.
Wrap data in a settlement request transaction and send on-chain to the coupon smart contract agent.

The Tokenized Settlement Request is embedded in this transaction.

The MessageCode 1003 means the MessagePayload is a Settlement Request and it decodes to this.

And here is the decoded Settlement data.

This combined with the Tokenized Transfer transaction previously received provides all the necessary data for the coupons smart contract to complete the Tokenized Settlement transaction (minus final signatures from the pounds sterling smart contract).

Coupon Smart Contract Agent Receives Settlement Request

The smart contract agent for the coupons James created receives the settlement request on-chain and responds. This agent previously saw the transfer request, but knew the other agent was first and waited for the settlement request.

Unwrap settlement data for the pounds transfer.
Verify that James has the required coupon tokens to transfer. In this case, no identity oracle signatures are required for the coupon recipient.
Add settlement data for coupons transfer.
Determine settlement data is complete for all assets, create a settlement transaction, and sign it.
The settlement transaction is still missing signatures from the pounds smart contract agent, which weren’t possible until the coupon’s settlement data was added, so the settlement transaction is wrapped in a signature request transaction and sent to the currency smart contract agent on-chain.

The Tokenized Signature Request is embedded in this transaction. It decodes to this.

The MessageCode 1002 means it is a Signature Request (same as between James and Scott above). It decodes to this.

The payload is a Settlement transaction that is only missing the currency smart contract signatures to be valid. Again skipping this for brevity.

Currency Smart Contract Agent Receives Signature Request

The smart contract agent for the pound sterling tokens receives the signature request on-chain and responds.

Unwrap settlement transaction from signature request transaction payload.
Sign inputs belonging to the currency smart contract agent.
Broadcast settlement on-chain.

This is the completed Tokenized Settlement transaction. It provides the new token balances of each Bitcoin address involved in the transfer. It decodes to this.

Users Receive Settlements to their Transfers

The users see their transfers have been accepted and settled on-chain by the required smart contract agents. It is atomic because it is only valid if both smart contract agents sign. Either smart contract agent can reject and invalidate the request.