HyperToken Standard

[EricForgy]

https://twitter.com/EricForgy/status/1632250272214048768

Should we start a discussion around what a non-EVM HyperToken standard should look like?

[EricForgy]

One thing I don't like about EVM is that each token is in a separate contract and knowing someone's balance across all tokens requires querying every single ERC20 contract. I want to build a custom VM where token balances are not siloed in separate contracts, but part of a user's data structure.

With ERC20, each contract keeps track of user balances:

I want a VM where each user has a wallet / portfolio that stores their balances for each token in one place:

This is kind of like a transpose of ERC20.

Each address effectively has a wallet that keeps track of what tokens it owns and what the balances are. Balances are not managed by the token contract.

ERC20:

mapping(userAddress => uint256) balances

New model:

mapping(tokenAddress => uint256) balances

With EVM, the only balance that is maintained locally is the native token balance. This legacy model was created long before ERC20 existed.

With the proposed model, we can implement something more like "request-response". This would not require allowances.

Request: "Here are 10 token A. Please send me token B."
Response: "Ok. Here you go. 10 token A in = 20 token B out. Here are 20 token B."

Thinking about this inspired me to consider graph databases for custom VMs since that would be easier to query.

Any thoughts?

[EricForgy]

Maybe HyperToken should be an ANT?

https://twitter.com/0xPelano/status/1632251137163415552

[patrick-ogrady]

Right now, the TokenVM stores balances as owner|asset. This means you could easily get all balances for an owner by doing a prefix iteration over owner without needing to query all assets/storing everything in a special region of state dedicates solely to "owner data" (which can be quite restrictive/unclear what happens when this gets large).

[patrick-ogrady]

Doing this generically (across all sorts of VMs) definitely gets much trickier. I think one "draconian" technique would be to impose some sort of interface requirement on any HyperVM to service all balances (so that they must be stored efficiently) but this seems heavy handed (may specify balance units/how to identify assets/etc).

[patrick-ogrady]

The standardization/flexibility tradeoff has been on my mind a lot lately. I plan to think much deeper on this once we get the WASM executor off the ground.

[EricForgy]

I had a lot of fun participating in the Avalanche Community Developer Call:

https://youtu.be/hkGl_eCxGWQ?t=4021

In there, I referred to this Discussion and think it is important to start a conversation about what a good foundation for a VM looks like that is most suitable for financial services. EVM and ERC20 are not great.

It sounds like Patrick already has a great start with TokenVM having the owner|assets model versus the ERC20 asset|owners model.

Another thing I mentioned during the call, and I think is actually quite important for onboarding capital markets onchain, is to etablish a good accounting system as a native to the VM and not tagged on ex post. It might sound boring, but I think we should embed double entry accounting into the VM.

One thing all chains are missing today is the concept of a liability. As a result, any protocol that involves liabiities, e.g. lending and insurance, are fairly convoluted to implement. All accounts onchain today are asset accounts. We need liability accounts. We need onchain balance sheets and income statements.

As an example, consider an AMM. The asset tokens are, well, assets. LP tokens are liabilities. With double-entry accounting, you always debit one account and credit another in the exact same value. When you swap asset A for asset B, you are debitting asset A, which increases the pool balance for asset A, and debiting asset B, which decreases the pool balance for asset B. On the other hand, when you provide liquidity to the AMM, you debit asset A (assuming single-sided staking), which increases the balance of asset A, and you credit the LP tokens. However, since LP tokens are liabilities, when you credit a liability, the balance also increases. The makes implementation on EVM, which only has assets, is a bit clunky and convoluted. We can do better.

I know it sounds boring, but I don't think that this kind of basic accounting should be implemented as a smart contract sitting on top of a VM. It is so fundamental, I think it should be a part of the VM itself.

I'll see if I can get Julie in here to chime in from an accountant's perspective 😊

[EricForgy]

Any thoughts @juliux9?

[EricForgy]

https://twitter.com/punk6529/status/1634338612266389504

[paOol]

I agree that EVM token design is not ideal. I don't have a spec/standard in mind, but I will add that it should be extensible.

Today, some popular features of tokens include things like sAVAX (staked tokens), veAVAX (vote escrow token), etc. The problem is these each require a new contract at types (unless the existing one is upgradeable).

The business logic of these features should be built into the VM instead of having a smart contract for each token. This would serve a few purposes.

• Security, a lot of exploits slip through the various contracts of all the tokens
• opt-in , some tokens will want some features, not all.
• accessibility, It's easier to make an RPC call to create a token than it is to deploy a smart contract

For example, lets say we create a DAO module. This converts a regular token into a profit sharing one. You launch a dapp and the protocol revenue is locked into a treasury contract. If you own 20% of the tokens, you are entitled to 20% of the treasury.
Adding this module would require a transaction that changes the metadata of the token like so

name: DaoToken
features: []

to

name: DaoToken
features: ['DAO']

[Islandersfan2016]

Perhaps your concern about EVM token design is really more of a Solidity concern. I believe some of the token design issues you mentioned can be solved if the contracts were in Vyper.

https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC20.vy

[juliux9]

overall i think standards spec for these types of things are worth engaging on sooner rather than later. @patrick-ogrady mentions the "standardization/flexibility tradeoff", which is a ubiquitous question in systems design and also an obvious result of the powerfully customisable subnet scaling vision

TokenVM notwithstanding, to some degree i think furtherance of the discussion is beyond the technical scope of hypersdk. this is mainly because i think the value of, for example, a token standard, mainly emerges in business and operations, and presents itself at the implementation level as a (hopefully) useful pattern of voluntary constraints. in particular what i would like to see with something like this would be:

• informational efficiency -> which drives business value, neatly dovetailing into existing financial best practices such as Basel III reporting, double entry accounting and balance sheet disclosure, all leveraged by the obvious technical advantages that blockchains have in publishing this information

• operational efficiency -> that the information above is thoughtfully indexed for retrieval, and that general tooling supports business and technical development fluidly in this regard (eg. indexers, block explorers etc can provide base homogeneous leverage for derived heterogeneous needs)

• technical efficiency -> strategic data structures and interface guidelines that avoid the "draconian" :D , but are also motivated by winning the hearts and minds of business developers looking for best practice methodologies that harness the breadth of possibility on offer with avalanche tooling

happy to be part of any working group that drives this discussion forward

also want to acknowledge @EricForgy's concern here, that sometimes toy examples become industry standards accidentally. i think we can agree this is an outcome highly prevalent in many tech stacks and doubly so in crypto where a year old innovation is often grandfathered in as "the way things should be done". so absolutely believe in the timeliness of these questions

[patrick-ogrady]

It is an open question IMO if you can actually capture all features people want (and the way you implement the features people want actually work for them). Take a look at the ISO payment specifications banks use and you'll get a sense of what I mean 😬 . The beauty of smart contract-defined tokens is that every new token can evolve our idea of what a token is without merging a PR into the core of the VM (or hypersdk in this case).

This "healthy pessimism" is why we are pursuing WASM support before fleshing out a standard token format that we recommend everyone comply with. I'd rather see how people implement tokens and then survey what works and what doesn't (accepting the loss of productivity incurred before folks coalesce around a naïve standard we think of now).

I firmly believe in not enforcing a specification until you have a very strong opinion. I don't think we (or the community) have that opinion yet but am optimistic we can gather a strong opinion before the hypersdk goes to full production (so we don't run into a huge "re-work" event down the line).