TokenScript #43

[weiwu.zhang]

Pending agendas:

• Deck
• Allow random order elements (in token and in card)
• Framework of defining multiple tokens defined on one contract.
• Action-only token scripts use <token> or at least <cards> as the root element
• Moving token's originating contract's <address> to Ethereum namespace and thus make network="…" optional.
• <origins> vs distinct="…" round 2

Action-only TokenSCript

1. It starts with <cards>.
2. In the cards, there are no token attribute namespace. Therefore:
3. Any toke must be introduced by <input>.

Previously:

update(data) {
  data.token;
  data.card;
}

Now:

update(data) {
  data.inputs[1];
  data.inputs[2];
  data.card;
}

---

Proposal (pending rehinking)/

1. Removing <origins> for tokens

• The notion that a token is identified by an originating contract is questioned. e.g. in the case of AAVE token, such a design can only accommodate having a single (line of) credit token, instead of individual debt tokens. How likely will there be a case which there need to be two individual tokens?
• We agreed on using distinct earlier this year.
• <origins> is already used for getting attributes

2. Adding ERC20 and ERC721 TS as library with contract reference

<token>
    <origins>
        <ethereum:call contract="LendingPool" function="getUserReserveData" as="e18"
                       type="userReserveData" >
            <ts:data>
                <ts:address>…</ts:address>
                <ts:address ref="ownerAddress"/>
            </ts:data>
    </origins>
</token>

vs

<token>
    <attribute …>
      <origins>
        <ethereum:call contract="LendingPool" function="getUserReserveData" as="e18"
                       type="userReserveData" >
            <ts:data>
                <ts:address>…</ts:address>
                <ts:address ref="ownerAddress"/>
            </ts:data>
      </origins>
    </attribute>
</token>

---

FYI: Document project + Tokenisation Guide