Two assets with one Tokenscript? Request for comments

Tokenscript Design
1

Take DAI and xDAI for example. First, I feel that they are two different tokens, and should be rendered so in the wallet UI (although we can add some visual cue that they are connected, e.g. by linking one with another). The rationale is:

DAI and xDAI may not remain the same value. Both have a market. If xDAI's chain was found to have a security problem, xDAI will crash faster than DAI. DAI is an ERC20 token, meaning all the actions available to them (perhaps through inheriting an ERC20 tokenscript template) is available for DAI, not xDAI.

Now we recognise DAI and xDAI as two related but distinct tokens, the next question is if we should put them in the same Tokenscript.

The rationale behind putting them in the same Tokenscript is:

  1. They are signed by the same entity and ultimately owe their existence to the same stewardship.

  2. There are very similar actions. Let me elaborate:

Imaging when the user is buying something with DAI, but the DAI balance is insufficient, the Tokenscript for DAI might ask some xDAI to be converted. Let's call this "Conversion" action. For that, DAI Tokenscript needs to acquire permission to assess xDAI chain and proceed with the conversion.

The reverse might happen too when the user needs to checkout with xDAI and DAI balance isn't sufficient.

If it's possible to declare support for two tokens in one Tokenscript, the code would be sharable between (including CSS code) and permissions shared alike. If we don't do this, there might be inconsistency regarding "Conversion" action if DAI is using the latest Tokenscript and xDAI the earlier one.

Also, some tokens might be tight-knit for design reasons. Some projects experimented with having a twin-token structure for security tokens, where one token represents ownership and another right to claim the dividend. I personally think this is a case of overdesign - token ownership and the right to claim the dividend is called the same thing: "share" and it shouldn't be a problem to code both ownership and dividend login into one token. But let's say the designer of such twin token actually have a case where the two tokens need to separate. For example, one usually would borrow shares in order to short them, there might be the case that the lender wants to harvest the dividend until a certain date and the buyer agrees to obtain a share token without a dividend until then.

In general, we are not the guardian of good smart contract designs - tokenscript is often thought as an 'after product' of an already badly designed smart contract. I would assume whenever the requirements get complicated, the developer will decide "let's build a new token to do the new requirements". Having multi-token support in a single Tokenscript might be able to accommodate these inconsiderate designs.

The rationale behind one-token-per-Tokenscript is:

  1. It's likely inevitable to invent stuff like inheritable Tokenscript or component Tokenscript, where one Tokenscript refer to another to borrow actions and such, which might be more suitable than having more than 1 tokens in one TokenScript.

  2. It can be confusing when the user add Token A, Token B appears in their wallet with 0 balance which the user never intended to use. In our case, some users might only use xDAI and never for a moment thought about using DAI, and hate to see it hanging out there.

2

I think we have given it as much thought as 'blockchain speed' allows, by laying this issue there for 2 weeks.

My current (unchallenged) thinking is that a token script should support more than one token. Consequently, <action> is taken out from <token> and made itself to the same level as <token>†, since one of the motivation to include more than one token is to share actions. If you reserved your challenge for 2 weeks, now is the best time to challenge me since we are on the edge of implementing this.

† An <action> inside <token> is only applicable to that token, borrowing the html <label><input/>..</label> pattern.

However, the current fill-in name for the collective, <tokens>, also the root element, is unsatisfactory. It gives the impression that a TokenScript is a bag that holds any amount of token, with sharable actions or not.

3

Attempting to summarize our verbal discussion:

Being able to describe 2 (or more) assets within one TokenScript is a good story to tell. Based on the DAI/xDAI example above:

  1. Almost-transparent bridging, potentially cross-chain, atomically (we need some protocol-based ERCs in place) during DvP is really good
  2. Wrapping multiple closely related assets into a single TokenScript so you can transact with each one

One important counterpoint:

  1. We haven't worked out how the actions are defined. But in earlier discussions, the consensus is a declarative model is better than a programmatic one. If an action is available to two or more assets which has different implementations, the declarative model might be too difficult for TokenScript authors to learn and use, even if there is a working implementation. Simple differences can be just spelling differences in the smart contract function names and signatures; more complex ones could have different flow, e.g. you need to convert the native cryptocurrency from xDAI to DAI, or vice versa first before spending it as the other asset.
  2. Also beware of over-design
4

Cowardly rolled back a potential over-design (the design with more than one token in a token script), using git-rebase as you advocated.