Data/Event Driven

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:

  1. The dapp has to repeatedly enquire the blockchain to get the updates of the data;
  2. 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 relevant data. This allows a TokenScript Engine to substitute 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:

  1. 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.
  2. Which event might trigger which token attributes or status to update.
  3. 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.