Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructuring asset-related RGB schemata #44

Closed
dr-orlovsky opened this issue Jul 22, 2020 · 7 comments
Closed

Restructuring asset-related RGB schemata #44

dr-orlovsky opened this issue Jul 22, 2020 · 7 comments
Assignees
Labels
proposal New proposals [RGB] Specs related to client-validated state management system

Comments

@dr-orlovsky
Copy link
Member

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:

  1. Single-issuance fungible digital rights
    • non-inflatible
    • no burn procedure
  2. Securities
    • inflatible
    • burn procedure
    • no reissuance after burning
  3. Coins
    • inflatible
    • burn procedure
    • reissuance after the burn
  4. Collectibles
    • unique
    • multiple issues in series
    • burnable?
    • rich metadata

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.

@dr-orlovsky dr-orlovsky added [RGB] Specs related to client-validated state management system proposal New proposals labels Jul 22, 2020
@dr-orlovsky dr-orlovsky added this to the RGB core: drafts milestone Jul 22, 2020
@dr-orlovsky
Copy link
Member Author

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

@sabina-sa
Copy link
Member

sabina-sa commented Sep 14, 2020

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.

@dr-orlovsky
Copy link
Member Author

dr-orlovsky commented Sep 14, 2020

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.

@sabina-sa
Copy link
Member

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.

@dr-orlovsky
Copy link
Member Author

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?

@dr-orlovsky
Copy link
Member Author

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.

@dr-orlovsky
Copy link
Member Author

@sabina-sa With RGB-WG/rgb-node#19 I introduce "renomination" procedure which allows issuer (or a party defined by the issuer) to update all asset data, including:

  • name
  • contract (like text of contract, it's Ricardian representation or URL to it)
  • precision, which will allow "splits" (if it was decreased) or "joins" (if it was increased)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal New proposals [RGB] Specs related to client-validated state management system
Projects
None yet
Development

No branches or pull requests

3 participants