Just wanted to start a topic for discussion about higher-level token standards for CashTokens.
An excerpt from this post:
CashTokens Metadata Protocol
I’m currently working on a proposal for handling and authenticating metadata about CashTokens – the primary goal is to have a common standard for describing and representing various kinds of tokens in user’s wallets.
This is probably the most urgent higher-level standard needed since wallet developers need to be developing user interfaces for handling tokens. We want to be able to standardize on how wallets display a token’s name, symbol, icon, etc.
This related issue is also tracked by on the CashToken’s repo, where there’s already been some discussion: https://github.com/bitjson/cashtokens/issues/50
In short, I’m working on a Bitcoin Cash version of Token Lists (from the Ethereum ecosystem). This has proven to be a fairly successful strategy for distributing and authenticating metadata about tokens, and it is both simple and reliable. There’s even a multi-chain standard aimed at EVM-based coins. While we’re not EVM-based, matching our own standard closely with these existing systems should make implementation much easier for wallets – especially for wallets that already support tokens on other chains.
I’ll link the proposal here as soon as I finish a draft.
6 Likes
Looking forward to it man! Hopefully Electron Cash can be one of the early wallets offering either the creation or at least the display of token metadata.
1 Like
The high level question is where this information is stored and what follows is how the user can fetch the data.
Which basically is a boolean question of: does this need a new indexer ?
New indexers will lead to centralzation and censorship (see Tornado), a problem seen in most of the ETH infrastructure which is anything but decentralized.
As far as I am aware the ONLY sane way to avoid this centralization is to have the metadata in the genesis transaction and then add a p2p message to fetch a transaction by txid (since all full node implementations support txid-index).
Reading the introduction to Introducing Token Lists there is this very true statement;
As the decentralized finance movement continues to remove gatekeepers, it is imperative that new systems for discovery and reputation do not devolve into centralized gatekeeping.
But then we continue with their solution, and like so much of the ETH ecosystem, they claim to be decentralized but are not.
The idea is simple - any project on Ethereum that maintains a list of ERC20 tokens hosts this list publicly following a standard JSON schema. Projects attach their reputation to lists by hosting them on a domain they control.
[snip]
For example, an interface could automatically display any tokens that are on at least m out of n reputable lists. Or it could display all tokens across a set of lists, but display trust scores based on the number lists an asset is on. Or it can build in a list explorer that allows any user to import the lists that they want to trust.
What are problems with this:
- it creates a permissioned system. You need to get listed on a “reputable” list in order to be visible in wallets. The enire premise of removing gatekeepers not been hit in that project.
- The proposal to have various people run lists is going to hit the problem that this is not cheap. As usage grows, it will centralize. As reputation becomes important you will get network effects creating an even stronger centralization force.
- An individual can only check if a list is correct or false by either checking another list or themselves creating a list (which is expensive). Which fails the basic concept of the truth being the blockchain. Why is this important? Because they created a new layer which can be corrupted and made political.
My thinking is that the first quoted part is the most important one. One they got right but then failed to actually solve:
it is imperative that new systems for discovery and reputation do not devolve into centralized gatekeeping.
One imprvement to this I would add is this:
Keep as basic truth the blockchain and merkle-proofs and separate features that will cause centralization like reputation and curating.
If you conflate the storing of metadata with the need of a reputation system then you will stop wallets from being able to fetch basic data about a coin unless its been permissioned to be shown in wallets. The only thing that can not be censored is data on the blockchain. Depend on “lists” and you introduced the ability for censorship, KYC and all that stuff.
I’m writing this as I know this will come back to bite us and I have to have done the best I could to document this now. Hopefully Jason will reconsider my proposal from the linked bug report before the deadline.
1 Like
Jason reached out yesterday and we had a phone call to talk about the problems and possible solutions.
I’m happy to say that we basically are saying and thinking the same thing. He also agreed that using the ETH “Token Lists” may have been a bit confusing as an example for a solution.
I’ll let him explain the ideas for recording the metadata on chain in detail, but here is the short short version.
We can define a ‘metadata-baton’ (not entirely unlike an NFT), in a way that we can implement it with basic transactions. Using things like OP_RETURN we can add metadata and the baton allows one to decorate the identity with more details in follow-up transactions, or change things in some follow-up transaction.
The idea of a baton means you have a series of linked transactions which together make up this identity. They can get mined as normal. You can’t really burn the identity with a not-supporting wallet, but you do want to keep the private key that owns the identity separate for obvious reasons.
Some thoughts on the protocols that this post is actually about:
-
A token metadata is basically an identity. And then I think that we had this fun experiment called “Keybase” (still running, but now owned by zoom) which probably means we can steal various ideas from them.
-
An identity can be associated in real life with another identity or an external site. I could have a public persona on-chain and that public key can be used to verify a file on my website attesting that identity owns my domain. This can be linked back into my chain for external verification.
-
BIP69 sorts outputs for anonymity. (Supported by BCHN, Flowee Pay and likely others). The good thing is that the lowest amount output is output zero, which is almost always what you want to be locked up in your personal chain anyway. The bad news is that op-returns outputs should have zero in the output field, so they will be sorted first.
I would suggest to make the validation of the chain do more work and allow skipping of the op-return output to carry the baton forward. Because any other option I can come up with will just lead to invalid chains or loss of the baton. -
I’m thinking it would be useful / a good suggestion that wallets or identity managers use a different HD private key for almost every transaction while carrying the baton.
The advantage of regularly swapping out private keys that own the identity is that it can for the most part solve the “are we looking at the most recent” problem by having a requirement to sign a challenge with the most recent key. Making it instantly clear when two sides disagree what the tip is. -
Payment protocol upgrades we’ve been talking about on Payment Protocol will benefit from the inclusion of a full-identity-chain in some way or another. So likely they would both want to use the same formatting, or include it as a binary-blob. IDK.
-
While any 3rd party observer can use the blockchain to identify and trace / update the worldwide total set of identities (search-engine style), I think its important to focus on the idea that most websites / companies are not forced to do so. Instead the protocols should allow the customer to provide the chains to the company (for login, for instance).
In most cases a simple merkle-proof check is enough exposure to the blockchain, then.
3 Likes
Hi all! I just shared a draft proposal here:
3 Likes
Reposting a message from CashToken Devs:
RE dividends: I think we talked about this briefly in the BCMR tech talk (Bitcoin Cash Metadata Registries (BCMR) Tech Talk + Q&A (Nov 1, 2022) - YouTube), but wanted to get it written out for reference too.
I spent a good portion of last year experimenting with ideas around dividends, so just want to share some of my learnings and maybe save others some time/effort. (I’ll write a proposal for a dividend standard eventually, but need to wrap up this compiler/IDE refactor to be able to design/verify the contracts.)
The fundamental question: how do you pay a dividends in a 24/7 market that supports non-custodial contract systems?
Legacy securities markets “close”, so there’s a simple way to decide who owns a particular security in time to receive a dividend: “close of trading” on dividend days. Legacy markets are also strictly custodial: you can always send dividends to the registered holder of a security, and the legal “contract system” will ensure that the beneficial owner ultimately receives the money.
On Bitcoin Cash, we can expect that markets will continue to operate 24/7, and introducing an artificial “close” is actually really hard. E.g. if dividends pay out at 12 UTC MTP, coordinating with wall clock time is a mess and can introduce MEV, and then there’s the “ex-dividend” price drop to worry about, made even worse by the global nature of BCH markets: the tax-adjusted drop will be more different across individual shareholders than in traditional one-country markets.
And that’s only half the issue: you also have to know where to send the money. If you limit it to P2PKH, 1) your asset will globally grind to a halt shortly before the dividend as people pull shares from liquidity pools, limit order books, escrow systems, etc.; 2) you outright prevent economically-rationale actors from using many time-delayed, multi-entity, and hardware security systems across dividend periods (and you’re still likely to cause your investors to burn money, e.g. in hardware security modules). However, blasting money at non-P2PKH contracts is likely to burn even more money: vaults/channels may accidentally give counterparties control of dividends; time-delays and pre-commitment systems could lock up or even permanently freeze dividends; decentralized applications could be thrown off by unexpected infusions of cash (accidental liquidity pool rebalance == fire sale of the token); etc.
All this to say: I think dividends on BCH should be “pull-based” rather than “push-based”. To pay a dividend, you deposit the money in a trustless covenant, and shareholders – at their leisure – burn their pre-dividend tokens to receive the dividend and an equal amount of post-dividend tokens. Now global markets can power right through the moment of the dividend: decentralized exchanges continue to trade the old tokens at pre-dividend prices, and the new tokens simply begin trading at post-dividend prices. Shareholders can continue to sit on their old tokens indefinitely: leave them in cold storage, time-delayed vaults, liquidity pools, order books, etc. with complete confidence that their dividend is sitting on-chain for them in a covenant that will always honor the dividend (even if the issuer has gone bankrupt!) When the shareholder is ready, they can e.g. pull old shares out of cold storage and pass them through all the dividend covenants issued in the past X years.
A lot of the effort behind the BCMR chip (https://github.com/bitjson/chip-bcmr) was making this ecosystem work as smoothly as possible. Wallets will be able to show the name/icon/etc. for a particular token, look up the whole history of a token’s category ID changes and the relevant dividend covenants, then show the users a simple “Unclaimed dividends” balance.
All that said, I don’t want to discourage anyone from building simple P2PKH-only, push-based dividend payout systems for immediate use with CashTokens. Until we have much of this other infrastructure, push-based systems will work fine. Hopefully, having a vision of what pull-based dividend systems might look like will help people optimize their time/energy investments. 
3 Likes
The BCMR standard for metadata has gone through some changes and is already used by multiple CashTokens project on BCH mainnet including wallets, a blockexplorer and an NFT marketplace.
The BCMR standard is general enough to cover multiple items of the initial list of low-level technical token standards needed:
So the ones still missing from the original list of general (non-industry specific) token standards are
The only SLP token project I’ve heard talking about migrating is SPICE token. They issued a SBCH token as well. There are other SBCH projects which want to migrate like the Reapers NFTs.
One month after the CashTokens activation and different methods for creating collectable NFT collections have been tried in real projects: Bitcats Heroes used a minting contract to create their NFT collection and the Bch Guru pre-minted the whole supply of collectible NFTs. Indeed it might be helpful to have these methods written up as standards that can be used by future projects.
An important standard missing from the list is a standard for having fungible tokens with “minting baton” functionality. This was a feature of SLP that was popular but for CashTokens a standard and tooling have not been developed yet so practically speaking this functionality is still missing.
1 Like