Closed dr-orlovsky closed 3 years ago
After the call we have decided not to have the burn and history truncation procedures for initial collectible schema. For more complex cases, we will be designing more schemas with the time
There is a feature that is quite popular with exchanges: “split” for stocks or “redenomination” for coins. Corporations like Apple often split their share so that it becomes more affordable, and I recall that Polkadot had a redenomination recently. “Split” or “redenomination” means that every holder of an asset gets an "airdop" of multiple assets of the same type. It looks like issuing new assets, but in reality it is not that, but instead it is a change in the way that the assets are counted, e.g. as if we switched from Bitcoins to Satoshis. Maybe we could implement it on RGB schemas, in a way that this is not confused with issuing new assets.
The point of RGB is to have equation "once we reached agreement, some party can't change it without your explicit consent; even if the majority votes for it". So it's not a tech problem, but a governance problem: RGB have no governance after genesis; not even issuer or majority can decide. It is a feature.
My worry is that absence of splits makes RGB less compatible with normal stock exchanges. "We can't do a stock split" - that might be an argument against listing stocks in parallel on RGB along with a normal stock exchange.
Who will be taking decision? And how to avoid contradiction to the main principle "you can't force owners into something w/o their permission?"
Were there stock splits for bearer-right assets?
What we can do, is that we can have a "split right", which will be defined at the level of asset issuance in genesis for shares schema, and use this right to perform a split action. This will complicate schema, but it will grant the issuer an option to define that right holders, and all those who will be owning assets will know about such possibility from the very beginning.
@sabina-sa With https://github.com/LNP-BP/rgb-node/pull/19 I introduce "renomination" procedure which allows issuer (or a party defined by the issuer) to update all asset data, including:
As was discussed during the dev call on 15th Jul 2020, use cases for different forms of tokens (stable coins, shares) will benefit from having separated schema. Here I propose to define the following set of schema for all asset-related cases:
All of these schemas will be proxied by a single
asset
RGB contract daemon (inside RGB node) with a single standard API for reducing the complexity of integration from a wallet perspective.