Where does the signed TokenScript live and where does the rendering take place?

Tokenscript Design
1

Once the TokenScript is signed by the issuer, is it stored in the holding smart contract, correct? Before being used in a Dapp, the TokenScript would need to be queried out of the Dapp before use, right?

So, if I was a DApp selling Pizza for example, where does the actual rendering of the token take place? For example, maybe I wanted to accept Pizza Payment Tokens (PPT) as payment and utilise Pizza Delivery Tokens (PDT) for the delivery. In the top-right, I'd like to show the user's current PPT balance and I'd also like to show PDT held by the user after the purchase occurs (similar to the screenshots in the design paper).

I was under the impression a lot of the rendering was abstracted away from being the responsibility of the DApp, and instead handled by the signed TokenScript itself. Is the idea to create some sort of UI components that we could use inside of a Dapp, or is the rendering meant to be mostly used inside of a wallet (in which case, the Dapp could use the traditional methods of querying for a token balance and display it in the Dapp)?

3 Likes
2

Hi @emizzle,

We discussed this on Telegram but I will write this up for posterity.

Initially, we will serve TokenScript files from our 'repo server' but as it gains more usage, the issuers web site can provide the file to the user who just interacted with their service. You can also manually drop the file for debugging.

TokenScript can hold and render a layout (in the form of HTML, CSS and JS) but this must be canonicalized and therefore all references to JS and things like Images must be included in full and not referenced by a URL.

When a user has access to the TokenScript file (either on the web or on the mobile app), the layout and other core functionality are included and signed by the issuers key to ensure authenticity and that it hasn't been tampered with. You could therefore copy a lot of the layout you have on your dapp and adapt it to be used in TokenScript (without the need for the dapp browser or web3.js transaction calls).

Thank you for your question!

2 Likes
3

What are the benefits of doing in this way? @weiwu.zhang

4

This is actually a pretty good question, I wonder how I missed answering it in May.

For example, maybe I wanted to accept Pizza Payment Tokens (PPT) as payment and utilise Pizza Delivery Tokens (PDT) for the delivery. In the top-right, I'd like to show the user's current PPT balance and I'd also like to show PDT held by the user after the purchase occurs (similar to the screenshots in the design paper).

Let's look at PPT and PDT separately. If a user has PPT (Pizza Payment Token), he should already has the TokenScript for that token running in his wallet (he obtained it when he acquired the token in the first place), which can handle the balance display in the checkout together with its token action (like "spend 100 get back 20"). The interesting thing here happening is the PDT: Pizza Delivery Token.

Since your website sells Pizza, you should know what actions are relevant to the users. Let's say the Pizza delivery token has 4 actions.

  1. Redeem pizza.
  2. Authorise someone to redeem pizza.
  3. Share your recipe.
  4. Get 1 for free when you have purchased xxx.

Let's say that you run the Pizza operation from a vantage location and you are not doing "Get 1 for free when you have purchased xxx" promotion per se. The smart contract for managing the pizza token (likely not made by you) has the function to do so, you just don't enable it for the Pizza tokens issued by you. What you can do is:

  1. Get the signed TokenScript available for PDT (the PDT contract author has it on their website or they can email it to you).
  2. Delete the 4th action card (this won't break the signature if you do it right)
  3. Serve it from your web site
  4. Link to it on the checkout page of your Pizza website through a reference using HTML <link> element.

What the user does is this:

  1. Checkout (use "spend 100 get back 20" action if he can).
  2. Hit "confirm" - he gets a confirmation screen where he sends the Ethereum transaction. At this confirmation screen, the slimmed down TokenScript is used to render the PDT on the confirmation.
  3. When the Pizza Delivery Token arrives† the user's wallet, the TokenScript is activated to display the token in the user's wallet (with a countdown if pizza is ready soon) and allow the user to perform the actions (like "Redeem Pizza" which might display a QR code at the shop)

† The actual smart contract event which signals the arrival of the token is in the TokenScript he downloaded at the confirmation screen.

Now let's circle back to the problem how did user acquire the TokenScript for PPT in the first place. The TokenScript for that token is provided by the website which sells that. It can be from an imaginary Pizza Token Association which metes out such tokens to members, or it can be your pizza website too, a bit like Crown Plaza selling casino chips and the stuff that casino chips can be used to buy. In reality, though, I don't think there will be a Pizza Payment Token at all. In the Internet economy, there are only rooms for a few payment tokens. Most likely, the user acquires a Pizza Gourmet token which can't be used to pay for Pizza but allows 10% discount for Pizza paid in Ether or any other payment token.

Now, to Victor's question:

What are the benefits of doing in this way?

  • A website knows when the user is about to get a token, and what actions are relevant to the user. It can smartly provide actions without the user downloading 1MB TokenScript at the outset. Normally, if you use a website, the content is downloaded on the go. The users don't first download a full website then start browsing, so why TokenScript should be different.

  • If a token is acquired through using a website, the website can be assumed available, hence having TokenScript there doesn't add additional availability constraints. Had we designed in such a way that the user acquires a token through transacting on a website, the TokenScript, however, comes from github, then the users can only successfully acquire and use a token if π‘π‘œπ‘‘β„Ž your website and github are online.

  • TokenScript itself is designed to run actions in a security sandbox (implementation pending). It needs to interact with the web elements surrounding it. Having it linked in the webpage allows such interaction. This kind of interaction isn't apparent in the "checkout" case because Pizza is a simple product, but very relevant if the user is getting a Legendary Elf Sword in a game.