CIP - Callback (buy back) for reusable assets

Development Counterparty
1

This is an updated re-post of my comment in the topic referenced below.

Introduction

It appears some assets (use cases) would benefit from the ability to be called back. Now we have subassets so on the one hand you can create disposable subassets, but in some cases it’d be better to have an asset (or subasset) that does what the name says it does, rather than have to look it up in a database or Web site.

Use Case 1: Reusable Tokens

Certain assets - if you want to reuse them - should be callable. Let’s say bus tickets (reservations).
Currently we can issue assets or subassets with random names that can be exchanged for bus tickets, but in cases where there’s only one of a kind, and the use case mandates that it changes hands, it’s be better if we could reuse it.

In this use case, these should be callable at 0 fee (but the issuer could optionally pay more; if acceptance of callback offers is no required, then the price should default to 0).

What happens if the issuer calls back and “steals” tokens? An even cheaper and easier way to steal money is to never deliver the service. Some degree of trust in the owner is required to buy them in the first place.

Use Case 2: Loans and Rentals

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.

Rental / Subscription

Another use case is where we want to hold 1 GYM token for a period of 5 days.

You could pay rent membership for a week (say for 10 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.

Use Case 3: Restricted Access

We can sell a membership token, but we can’t cancel (revoke) it.
This makes it hard to use tokens as means of membership or access control.

While revocations could be arbitrary they could also be multi-sig driven, where elected or appointed representatives could decide to revoke someone’s token. We can’t revoke a token from designated address, so this would apply only to subassets where 1 is held at one Bitcoin address.

In case of asset-level memberships, say JEFFSPOOLBAR, all tokens could be revoked (called back) on Dec 31 2017 and those interested in extending their membership would have to re-purchase them for 2018.

Implementation Considerations

We’d have to make sure that callback-able tokens can’t be locked or otherwise encumbered.
Or else we’d have to create a backlog of sorts, to collect them when they become unencumbered, but then we’d need to hold buy-back funds in protocol’s escrow for a while, if we made it possible to buy back for a price higher than 0).

Another issue would be that such assets could be sold or protocol-locked in BTCpay order match or something like that. Maybe a way to address that would be to prevent DEx matching or settlement for called-back assets, or create a new type of order (callback order) which would take matching precedence over other DEx buy orders.

Reference

  • There’s a CIP for a similar use case, asset “reset”: change a reg’d asset that hasn’t been distributred, from divisible into indivisible.
  • There’s a feature request that could be applied to this CIP

https://github.com/CounterpartyXCP/counterparty-lib/issues/1020

2 Likes
2

Would be a useful feature for sure!

The project I run has already seen several participants (musicians) lose their keys. If I could call back the tokens in those lost addresses and send them to their new addresses that would be nice. People are going to lose their keys no matter how many warnings are given about backing them up. While it gives the token some sense of more value because of the fact it can get lost, it isn’t always the case. The token here is basically a means for participants to receive any profits the projects generates. If that were to happen we’ll basically be burning BTC because of those lost keys. Which kinda bugs me, that could be better spent on something else.

1 Like
3

Excellent use case - if subassets could be called, then you could call back individual keys.

4

The utility that this could bring to the platform is significant.

5

Generally I think restoring the callback functionality is a great idea which would definitely bring some additional functionality to the platform.

However, I am still not sold on the idea of being able to call back specific tokens from a given address… while I agree with @WillH that the functionality does add some value, I am not sure that the positive benefits would outweigh the negative.

When I purchase a token, I expect that it will stay in my wallet under my control until I move it (this is how it is with pretty-much every cryptocurrency). If when I purchased the token it was made clear that the token could be called back in the future and if it was called back in the future, I would get something of value returned to my wallet, then that is understandable… a user is taking some risk in purchasing the token, but they will get something of value in return if the token is recalled in the future.

If however I am purchasing a token and that token can be recalled from my wallet at any point for any reason without any explanation, that would certainly give me pause… Here are a few doomsday scenarios for this functionality:

  • Hacker gains access to private key for asset owners address… and recalls all user tokens.
  • Rogue Actor / Bad Employee sells tokens to users and then calls them back a few days later
  • Shady Project Operator does ICO and sells tokens… then starts randomly calling back tokens of anyone who calls them scammers

In all of these above scenarios customers are damaged because

  • All TX fees used to move asset around network are essentially wasted
  • Customers are out tokens/funds without any sort of explanation or recourse

For the above listed reasons, I think that callbacks should only be enabled with the ability to specify a callback date and price, and no ability to callback specific tokens from an address.

Personally, I would like to see that this new callback functionality gets incorporated into CIP3 (or an extension of CIP3) so that existing asset owners in control of 100% of the supply would be able to :

  • Destroy any existing supply
  • Change token divisibility (after all supply is destroyed)
  • Issue additional supply
  • Issue additional supply with callbacks enabled (all supply must have same callback logic)

side-note: @something I really like the idea of disabling DEX order matching for any assets that have been called back… nice :slight_smile:

6

I think the keyword here is expectation.

If a cryptocurrency type of token is what is expected, any kind of callback would be detrimental.
On the other hand, if the token is providing a service, a callback would be totally understandable and people would be okay with it. That of course depends on the circumstances surrounding the callback. But I guess since we would know if it’s a callback token the same way we can check whether a token is locked, we would treat and think about a callback token differently from an uncallable one.

There’s probably many good use cases we can come up with. For example game items. If a callable-token is an item in a game, that item can be transferred between two players by the game provider. Any item that’s dropped, picked up, won, or lost would be handled server side (possible smart contract usage?), making it a seamless experience for the players.

If the game provider decides to callback tokens for no specific reason, users will react to this like they did with EA and the Battlefront microtransactions. Doing something users don’t like is bad for business.

As for a game item becoming compromised, whether it’s by bad employees or losing access to the private key, it can be resolved thanks to the blockchain. The game provider would know when, where and what has happened. The compromised token would be taken out of the game and replaced with a new one. The new token would be sent to addresses that had the compromised token before the incident by bad actors. It would still suck for the game provider as there’s costs involved with sending out new tokens, plus the headache of rebranding a token. For the users and players though, not much would have changed.