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