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 makenetwork="…"
optional. -
<origins>
vsdistinct="…"
round 2
Action-only TokenSCript
- It starts with
<cards>
. - In the cards, there are no token attribute namespace. Therefore:
- 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