CIP - Reset Token & Divisibility Statuses for Unused Asset


#21

I’ve been claiming the same for a long while. Whatever important uses people come up with, they will be rendered useless by the state.

If bitcoin can’t break out of niches without economic and political relevance and significance, what does that say about its future? If one can only use it for apps which can also use Visa or PayPal, there would be little point in using it at all. This post explains why the only uses that matter are free market apps and without them we might as well use a permissioned garbagecoin.

@JPJA I think you have enough support to submit a draft CIP to Github for any final comments.


#22

Agreed. Please post here, in slack or fork the repo and create it in github. I/we can help you edit it if need be before we submit it to the official github repo.


#23

Ok, here it goes.
@deweller, feel free to edit. I copied your technical description and added you as author.

CIP: 3
Title: Reset Token & Divisibility Statuses for Unused Asset
Authors: JP Janssen
Discussions-To: CIP - Reset Token & Divisibility Statuses for Unused Asset
Status: Draft
Type: Standards
Created: 2015-12-03

Abstract

If the asset owner holds the entire supply and the asset is not locked, then allow the owner to reset the supply (e.g. set the supply at zero) and change the divisibility status.

Motivation

More than 30,000 assets are unused. If or when they get a use case it may be beneficial to change the divisibility status and/or reset the coin supply.

Rationale

The best asset names have been registered by squatters for the sole purpose of reselling them later. Future projects may want to buy these names. Currently an asset is stuck at the initial divisibility status and coin supply. By allowing the owner to reset these, the projects involved will benefit. If this is limited to assets where the owner holds the entire supply and the asset is not locked, I cannot see anyone being harmed by allowing this.

Specification

The create_issuance API call will include a new reset flag. A reset is valid only if the owner holds the entire supply and the asset is not locked. The divisibility status can be changed. The supply can be set at any value >= 0 (and below the upper limit).

Example use cases

Alice owns GOLD. The supply is 88,888,888 shares. Bob is setting up a GOLD ETF on Counterparty and intends to let one share represent 1 oz of gold. The ETF’s total supply is only 10,000 oz. Alice wants to sell GOLD to Bob, and Bob would have been interested if he could set the supply to 10,000 shares.

Carol registered ODIN long ago. Now she plans to make a card game with ancient gods. Players are encouraged to trade on the DEX but ODIN is divisible and cards should not be that. If someone puts an ODIN card for sale, a troll may match the order with a millionth of a card, hence destroying the card (this actually happened with a Spells of Genesis card)

Copyright

This document is placed in the public domain.


#24

Great. I’ll look at this later this week.

I appreciate the acknowledgement, but you don’t need to include my name on the poposal. I was just doing my job as CIP Editor.

Any others - please feel free to comment.


#25

Looks good.


#26

JPJA

I have the following suggestions and I am ready to merge this as a draft as CIP 3:

  • Please remove my name as an author. I don’t require authorship credit in the proposal.
  • Please change the Type to Standards.
  • Change “use-case” to “use case”
  • Move “Technical implementation” to “Specification”, write it as a more declarative specification and remove all of the “I think…” statements. (e.g. The create_issuance API call will include a new reset flag… ).
  • Please add a Copyright section (See https://github.com/CounterpartyXCP/cips/blob/master/cip-0002.md as a simple example)

Once that is done, please for https://github.com/CounterpartyXCP/cips and submit a PR as cip-0003.md.


#27

Changes made as you suggested. I’m not sure if what I wrote under Specification is good enough though.


#28

Great. I think the specification is good.

Can you fork https://github.com/CounterpartyXCP/cips and submit a pull request? Or do you want me to add it?


#29

Done. Pull request submitted.


#30

Great. This is merged.

The next step is to work up a pull request with an implementation. And before writing any code, I recommend discussing the plan of the technical implementation details with @robby_dermody or one of the founders.


#31

A wider (and the one that I’m also interested in) use case of callability, in my case, would be the ability to buy back portion of a float/issuance. When does this become useful?

Use Case 1: Reusable Tokens

Certain assets - if you want to reuse them - should be callable. Let’s say bus tickets (reservations).

In this case, these should be callable at 0 fee (why not, but the issuer could pay more; we could make the fee optional, but default would be 0).

I think this case is simple because there are no restrictions whatsoever. Tokens get simply swept from the current owners, no questions asked.

Use Case 2: Loans and Rentals

Note: who gets the dividend during the time an asset is rented out?

Loan

If the issuer issues 10 LOAN’s, sells each for 27 XCP while promising to buy back at 30 XCP before block 498’000. (It’d get tricky if buyback tokens ended up in nLock transactions or other unclear states).

Rental / Subscription

Another use case is where we want to hold 1 GYM token for a period of 5 days. You could pay not the full price of gym membership for the year, but just rent it (say, for 30 XCP). I assume you’d have to leave a deposit of 40 XCP and the owner would buy back their GYM token for 10 XCP.
Maybe this is similar to the first case (reusable tokens), but the duration and buy-back price could both be variable.

Smart Contracts or Expanded Basic Use Cases?

I don’t want CP to become too complicated, so if we could have a way to build these features in a Smart Contract layer, that would be a better option IMO


#32

@something - This CIP is already written in such a way that you can only reset a token that has either no balances or one balance owned by the asset owner. Your ideas may be more fit for a separate discussion.


#33

I also think that.
I just didn’t want to ask for my own CIP. I’ll consider a new topic.


CIP - Callback (buy back) for reusable assets