Data/Event Driven

TokenScript takes a data-driven, event-driven design approach

As of 2020, most of the token's function that goes beyond typical ERC20 transfer requires a host application. A user visits a dapp website that is specifically serving the functionality of that dapp. The existence of a host dapp is always assumed.

For example, if an AAVE token is nearing its liquidation position, a host Dapp can check the current collateralisation position and provide a warning on the host Dapp. But, if the host Dapp is not running, the user would not have learned of the dangerous situation. His main user agent - the wallet - remains dumb.

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 enables the wallet to do substitute the service of a Dapp.

In TokenScript, a TokenEngine 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.