TokenScript takes a data-driven, event-driven design approach
If a Dapp needs data from the blockchain, it can call a smart contract to ask for these data. The call is then routed to a blockchain node, and the Dapp would wait a few seconds for the call to return.
This works well in the scenario that a user accesses a website that runs the Dapp. But:
- The Dapp has to repeatedly enquire the blockchain to get the updates of the data;
- If the Dapp is not running in a user's device, the user won't get the update.
For example, if an AAVE token is nearing its liquidation position, a Dapp running as a website can check the current collateralisation position and provide a warning. But, if the Dapp is not running, for example, the user is jugging, the user would not have learned of the dangerous situation. His main user agent - the wallet - remains dumb.
Even the existence of such a "host Dapp", run by the token's issuer, might be called into question. With the example of a Car Ownership Token, an accident might have written off a car. Yet, a loan application (a "connected-system") may still try to sell the user a line of credit by collateralising the car. The connected applications can't be running the host Dapp themselves.
Instead of needing a host Dapp to repeatedly enquiring the blockchain for data updates, in TokenScript's design Attributes define a token's relevent data. This allows a TokenScript Engine to subsitute the service of such a "host Dapp" in the user's wallet or a system.
In TokenScript, a TokenScript Engine is at work on the web or in user's wallet. It maintains a set of token attributes and utilises the declarations in TokenScript file:
- How to fetch relevant data for tokens. For example, how to extract data from a smart contract function calls, to listen to an oracle or to examine an attestation.
- Which event might trigger which token attributes or status to update.
- What kind of events or changes are worth triggering higher level UX logic, for example, producing a warning, or trigger a pre-signed deal to execute.
This is achieved by having Token Attributes, events and data modules declared in a TokenScript file in a XML dialect, and having them signed by a Token Issuer.