A contract with tables that hold metadata (e.g. graphical logo, descriptive name) for each cryptotoken used in the Seeds ecosystem. The contract data provides a shared registry readily available to any wallet app or other application.
Why
Users should see consistent UI features for each token across applications, to minimize confusion
Adding new tokens should be logistically simple, as we expect DHOs and affiliates to be creating new tokens on a regular basis. Executing an action on this contract is simpler than updating data structures within the codebase of each application.
A human vetting role is needed to prevent token symbols & descriptions which are accidentally (or intentionally) confusing from entering the Seeds ecosystem
How
The contract has a "submit" action which contains fields uniquely identifying the token (e.g. HUSD token from husd.hypha contract on Telos mainnet) and extensible JSON data carrying metadata; this creates an on-chain table entry for the token. A subsequent human vetting process results in the token and metadata being accepted for use. The contract allows for granularity in acceptance domains (e.g. a token might appear on seeds-swaps but not in the Passport)
What
A contract with tables that hold metadata (e.g. graphical logo, descriptive name) for each cryptotoken used in the Seeds ecosystem. The contract data provides a shared registry readily available to any wallet app or other application.
Why
How
The contract has a "submit" action which contains fields uniquely identifying the token (e.g. HUSD token from husd.hypha contract on Telos mainnet) and extensible JSON data carrying metadata; this creates an on-chain table entry for the token. A subsequent human vetting process results in the token and metadata being accepted for use. The contract allows for granularity in acceptance domains (e.g. a token might appear on seeds-swaps but not in the Passport)