The data source for activities

Tokenscript Design
1

I'm sharing a bit of thinking in the workshop with Nick yesterday. We already know that having a clear activity view is important for users to find their way in the DEFI world and also in the web3 world, and that the original model TokenScript had, which is to source activity data from the events in the transactions, didn't work for 2 reasons:

  1. The events often does not include all the information to determine what has happened (where internal transactions has rich information albeit less certainty, i.e. the occurrence of an internal transaction does not guarantee the action is carried out successfully). Some projects don't emit events at all, e.g. Compound. This could have been solved if the contracts were written with proper use of events, and is an example of the "discipline doesn't scale" problem.
  2. The data needed to render helpful information to the end user is often not included too. Note that this issue is unrelated to the first. For example, whether or not a transaction is considered profitable depends on a few factors like the price of Ether, which couldn't be included in the event even if the smart contract designers are disciplined.

For 1) no good solution can be found without a good internal transaction source. But for 2 there is a quick amend and a good amend.

Quick amend

Pass a state variable to the JavaScript inside the activity cards that includes all the toke objects of the tokens involved. Example:

state = {
    'tokens': [
        {'balane': 42, 'symbol': 'WETH'},
        {'balance': 4, 'symbol': 'DAI'}
    ],
    'card': {'amountFrom': 4,
             'amountTo': 84,
             'contractFrom': 0x9890839740217,
             'contractTo': 0x90270438092,
             'intendedRate': .005,
             '_transactionHash': 0x8093809843,
             '_transactionBlockHeight': 091829,
             '_transactionTimeStamp': 9802810,
            }
}

Observe that this state variable contains a WETH token and a DAI token with their present state (current balance at the time of viewing) as well as the amount transacted (in card) element. This offered the JavaScript information such as how much balance the two tokens have now, on top of the transacted volume. This provides the JavaScript with more flexibility in rendering the UI.

Good amend

This involves the Activity card declare a graphQL query (which can be connected to thegraph nodes) and receiving the result of the query.

For now Nick is experimenting with the "good" method.

2

Hi Weiwu,

As we discussed and reviewed over the weekend. The use for GraphQL allows for a way to simplify the flow of data between the front end of the application and a backend. This by allowing for requests to a single end point with filters - which can be used retrieve data from multiple end points / or methods with specific rules (e.g. data of expiry > today, limit to 5). Also carry out any other tasks, as you would with a REST API.

There are examples of GraphQL using http requests and websockets. Allowing for a rest API style application, or event driven.

I'll take a look at creating a proof of concept of the Activity Card example with the technologies described.

This to look at solving issues shared in points 1 and 2.

The occurrence of an internal transaction does not guarantee the action is carried out successfully. Using web sockets (rather than http) may prove to solve this issue using The Graph (https://thegraph.com/) e.g. update the view after a transaction has propagated on the blockchain.

The data needed to render helpful information to the end user is often not included too. Where GraphQL's query design may prove useful in sending payloads that contain the precise data the web developer had requested.