Skip to content

Latest commit

 

History

History
85 lines (52 loc) · 3.82 KB

bsip-0045.md

File metadata and controls

85 lines (52 loc) · 3.82 KB
Raw
BSIP: 45
Title: Introduce 'allow use as bitasset backing collateral' flag/permission to assets
Authors: @grctest
Status: Draft
Type: Protocol
Created: 07/10/2018
Discussion:  https://github.com/bitshares/bsips/issues/80
Replaces: N/A
Superseded-By: N/A
Worker: N/A

Abstract

It's currently possible to impose new asset settings through MPA encapsulation without the permission of the backing asset's 'asset owner'.

This BSIP proposes to introduce a new asset permission/flag which enables the asset owner to enable|prevent MPA encapsulation.

Motivation

By encapsulating an asset (UIA/EBA|MPA) within a new MPA, you can impose new asset settings upon the underlying asset, to the possible detriment of the backing asset's 'asset owner'.

Rational

By providing asset owners this functionality, we can improve asset owner confidence in the finality of their configured asset settings.

Specifications

Create new 'allow use as backing collateral' flag/permission

Rather than create a system of inheriting permissions from backing collateral, a new flag/permission for 'allow use as MPA backing collateral' could simply prevent MPA encapsulation entirely at the discretion of the asset owner.

Existing assets which are currently configured as an bitasset's backing collateral would require this flag to be set default enabled (allowed). This couldn't be changed unless the bitasset reconfigured to an alternative backing collateral - impossible if supply is greater than 0.

Non applicable assets (PM & twice nested MPA) would prevent the flag from being enabled.

Existing assets currently not used as backing collateral could be set to disabled by default.

Discussion

Consequences of MPA encapsulation

  • Removal/Bypassing of market fees (if enabled)
  • Re-implementation of confidential transfers (if disabled)
  • Evasion of whitelist/blacklist (both user & market lists)
  • Preventing the issuer from transfering the asset back to themselves (Can't transfer backing collateral back to yourself)
  • Remove backing asset issuer from transfer approval provess.

Committee configuration

Should all smartcoins be allowed as bitasset backing collateral? Given that XCD already does this with bitUSD, I think it's appropriate. That said, not all committee owned bitassets are in a stable state (bitGOLD for example is in global settlement state right now).

Enabling the flag grants permisson for all

Currently you can perform MPA encapsulation without involving the asset owner, this could introduce conflict between the two asset owners.

If the flag is enabled, that's an indication that the asset owner accepts any bitasset use case - you wouldn't need to seek explicit permission prior to creating experimental bitassets on the BTS DEX.

If it's disabled, that's a clear indication that the asset owner doesn't want it used as backing collateral.

How to configure assets held by null-account?

It's possible that bitassets may be owned by null-account but remain operational, configuring default disabled would burn the possibility of encapsulation - if these assets exist then if possible should be set to enabled?

Proposed UI changes

This flag could only work as long as no MPA has already selected the asset as its backing collateral; setting this as default disabled (not allowed) for newly created assets in the asset creation form could help prevent the asset being used as backing collateral without the user's knowledge.

Summary for Shareholders

  • Introduces new asset owner permissions.
  • Helps mitigate negative MPA encapsulation consequences, improving gateway regulatory compliance capability?
  • Given enabled flags could constitute advanced permission for MPA use case, there may be UIA backed MPA created which would contribute BTS fees to the reserve pool.

Copyright

This document is placed in the public domain.

See Also

N/A