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)?

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).