Skip to content
83 changes: 57 additions & 26 deletions bsip-0048.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,45 +10,76 @@

# Abstract

The possibility of creating assets on the BitShares Blockchain is a core feature
of our platform. In the case of an ico, the ico-holders can create an asset with
a fixed maximum supply. However this maximum supply can be changed by the
asset creator (issuer) anytime. This exposes participators ico to the risk,
of loosing value of their bought asset.
The possibility of creating assets on the BitShares Blockchain is a core feature of our platform. However some things are too malleable when they should not be. Other things are not flexible when they should be.

With this BSIP a flag will be introduced which forbids the modification of the maximum
supply of an issuer created asset.
Asset creators can create an asset with a maximum supply. However this maximum supply can be changed by the asset creator (issuer) anytime. This exposes token holders to the risk of their purchased asset losing value.

With this BSIP a flag will be introduced which forbids the modification of the maximum supply of an issuer created asset.

In addition, another new flag will be introduced that prevents any more tokens from being issued in the future.

And finally, the ability to change the precision of an asset will now be available as long as current supply is zero.

# Motivation

The implementation of a flag, to disable the modification of the maximum supply for
issuer created asset, has effects for both sides. On the one side the security for the
participators or non-issuer users increases, because the value of their assets (tokens)
can't be manipulated by exposing the market to more created tokens. And on the other side
it is good marketing for the ico-hoders, because they can advertise with their fixed
maximum supply.
A flag to disable the modification of the maximum supply for an asset will be implemented. This has benefits for both the participants and the asset creator. Asset holders are assured the value of their assets (tokens) will not be diluted by issuers creating more tokens. Asset creators are able to market the fact that the maximum supply is fixed.

This can be very important in the case of Initial Coin Offerings (ICOs). Investors are assured by the network that their investment will not be diluted by new supply of that coin.

A flag to disable issuing allows asset holders to be assured that the current supply will not increase, even if there are unissued tokens.

The ability to change the precision of a created asset adds flexibility in the asset creation process.

# Rational

The `disable_modify_max_supply` is a new created flag in the `asset_issuer_permissions`.
The flag can be activated to forbid the modification of the `max_supply` (`asset_object.options`).
Once the flag is activated, it can't be deactivated.
`disable_modify_max_supply` will be added to `asset_issuer_permissions`. The permission can be activated to forbid the modification of the `max_supply` (`asset_object.options`). The related flag can only be set to `false` if `current_supply` is zero.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you have mixed up the meaning of permissions and flags.

This negative logic puts knots in my brain just from reading the BSIP. It will also be a PITA to implement. I think we should move these flags to positive logic. How many clients for creating assets are out there that might break?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How many clients for creating assets are out there that might break?

All clients.

Copy link
Copy Markdown
Contributor

@pmconrad pmconrad Oct 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think requiring clients to upgrade is better than being forever stuck with this twisted logic.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I clarified my permissions/flags statement. Please check. I have also switched to using positive logic. See 858b7ee

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's the way to go.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to revert to negative logic.

I agree here. If that twists user's minds we can present it positively in UI


`disable_issue` will be added to `asset_issuer_permissions`. The permission can be activated to forbid issuance of additional tokens. Once the related flag is set to `true`, it can not be changed.

Changing the precision of an asset should be easily accomplished with an `asset_update_operation`. This causes no harm while the asset is not issued.

# Specifications

This BSIP comes with a change to the protocol, which requires a propotocol upgrade.
However the changes to the code are minor.
This BSIP comes with changes to the protocol, hence requires a propotocol upgrade. However the changes to the code are minor.

For `disable_modify_max_supply`:

1. Add `disable_modify_max_supply` to the issuer permissions
2. Set `disable_modify_max_supply` to false for existing assets at hardfork time
3. Add a `can_modify_max_supply()` to the `asset_object`
4. Change the `asset_update_evaluator::do_evaluate` method to assert false for
1. the setting of the `disable_modify_max_supply` flag to `false` if `current_supply` is not zero or
2. the modification of the `max_supply` when the `disable_modify_max_supply` is `true`

For `disable_issue`:

1. Add `disable_issue` to the issuer permissions
2. Set `disable_issue` to `false` for existing assets at hardfork time
3. Add a `can_issue()` to the `asset_object`
4. Change the `asset_update_evaluator::do_evaluate` method to assert false for the setting of the `disable_issue` flag to `false` if it is currently `true`
5. Change the `asset_issue_evaluator::do_evaluate` method to assert false if `can_issue()` returns false
6. Change the `call_order_update_evalutator::do_evaluate` method to assert false if `can_issue()` returns false

To change the precision:

1. Add the `fc::optional<uint8_t> new_precision` to a new `asset_update_operation.extensions` struct.
2. Change the `asset_update_evaluator::do_evaluate` method to assert false if
1. `new_precision` exists and is not equal to `asset_object.precision` and `current_supply` is not zero
2. `new_precision` causes `max_supply` to be an invalid number

# Risks

It is believed that the addition of `disable_modify_max_supply` and `disable_issue` will add security for asset holders.

There is the risk to parties interested in acquiring the asset if the precision is changed after due diligence and before issuance.

# Discussion

Using `disable_` as names for boolean values is not advisable and can lead to confusion. However, these names were chosen for compatibility reasons. See the comments [of a similar situation here](https://github.com/bitshares/bitshares-core/pull/1375#pullrequestreview-164580457).

1. Add the `disable_modify_max_supply` flag to the issuer permissions
2. Add a `can_modify_max_supply()` the `asset_object`
3. Change the `asset_update_evaluator::evaluate` method to assert false for
1. the deactivation of the `disable_modify_max_supply` flag
2. the modification of the `max_supply` when the `disable_modify_max_supply` is set

# Summary for Shareholders

This BSIP proposes a way to improve the user security in the context of issuer created
assets.
This BSIP proposes a way to improve the financial security of users against the dilution of a held asset. It also provides a mechanism for asset creators to modify the precision of their asset.

# Copyright

Expand Down