I work on a wallet in my spare time. I save some notes here. May be useful to others too.
This is an SQL query to get relevant asset info (not checked, can have bugs)
SELECT asset_name, asset_longname, (SELECT sum(locked) FROM issuances WHERE issuances.asset = assets.asset_name AND status = "valid") AS locked, (SELECT divisible FROM issuances WHERE issuances.asset = assets.asset_name AND status = "valid" ORDER BY tx_index ASC LIMIT 1) AS divisible FROM assets
The entire table of all XCP assets is < 5MB.
A wallet that has this table will rely less on external APIs for divisibility and asset ID.
Without such a local table, different asset types depend on APIs to various degrees.
ASSET NAME vs ASSET ID
BTC & BTC have IDs 0 and 1. Divisible. Easy enough to hard-code in functions.
Regular named assets (like JPJA) have a mathematical two-way function to get from name to ID and back.
Numerical assets (like A14343250413609995459) have IDs which are simply their numbers.
Sub-assets (TYSONFURY.KO) are a special case of numerical assets. If entering the name in a wallet, the wallet should use this table (not an API) to lookup the ID. The subasset-ID relationship is set at the initial issuance and never changes.
This applies to regular, numeric and sub assets alike. Divisibility can change through a reset until the asset is locked.
Assets with locked value >= 1 have immutable divisibility.
All other assets should request an API. However, these can use the table as a sanity check. It’s extremely rare that divisibility changes.
Wrong divisibility means quantity off by a factor of 100M. Need to analyze what issues this can cause. Failed transactions only? Or loss of fund in certain situations?
Once the wallet is released and open-source, anyone who downloads and verifies the checksum (which includes the table too), should be confident that the table is correct. At least it should have been verified by multiple parties.
This unlike API which requires trust each time.
KEEPING TABLE UP TO DATE
A wallet with a local copy of the table will not have the latest assets. Also divisibility for older non-locked assets will be uncertain.
Updating the table would need an API, which in itself is as unsafe as relying on an API for every send. However, if several independent APIs are available, these can be cross checked, and it the table can updated safely that way.