├── BSIPs-Template.md ├── README.md ├── bsip-0001.md ├── bsip-0002.md ├── bsip-0003.md ├── bsip-0004.md ├── bsip-0005.md ├── bsip-0006.md ├── bsip-0007.md ├── bsip-0008.md ├── bsip-0008 ├── gui-mockup-0.png ├── gui-mockup-1.png ├── gui-mockup-2.png ├── gui-mockup-3.png ├── gui-mockup-4.png ├── gui-mockup-5.png ├── gui-mockup-6.png ├── gui-mockup-7.png ├── gui-mockup-8.png └── gui-mockup.pdf ├── bsip-0009.md ├── bsip-0009 ├── fee-dist.png ├── karma-exit.png └── karma.png ├── bsip-0010.md ├── bsip-0015.md ├── bsip-0016.md ├── bsip-0017.md ├── bsip-0018.md ├── bsip-0019.md ├── bsip-0020.md ├── bsip-0021.md ├── bsip-0022.md ├── bsip-0022 ├── changing-decay-parameters.png ├── general-vote-decay.png ├── historical-bts-voting-participation-rate.png └── historical-bts-voting-stake-with-hypothetical-decay.jpg ├── bsip-0023.md ├── bsip-0024.md ├── bsip-0025.md ├── bsip-0026.md ├── bsip-0027.md ├── bsip-0028.md ├── bsip-0029.md ├── bsip-0030.md ├── bsip-0031.md ├── bsip-0032.md ├── bsip-0033.md ├── bsip-0034.md ├── bsip-0035.md ├── bsip-0036.md ├── bsip-0037.md ├── bsip-0038.md ├── bsip-0039.md ├── bsip-0040.md ├── bsip-0041.md ├── bsip-0042.md ├── bsip-0043.md ├── bsip-0044.md ├── bsip-0045.md ├── bsip-0046.md ├── bsip-0047.md ├── bsip-0057.md ├── bsip-0058.md ├── bsip-0059.md ├── bsip-0060.md ├── bsip-0061.md ├── bsip-0062.md ├── bsip-0063.md ├── bsip-0064.md ├── bsip-0069.md ├── bsip-0070.md ├── bsip-0070 └── flow.png ├── bsip-0071.md ├── bsip-0072.md ├── bsip-0073.md ├── bsip-0074.md ├── bsip-0075.md ├── bsip-0076.md ├── bsip-0077.md ├── bsip-0081.md ├── bsip-0084.md ├── bsip-0085.md ├── bsip-0086.md └── bsip-0087.md /BSIPs-Template.md: -------------------------------------------------------------------------------- 1 | BSIP: 2 | Title: 3 | Authors: 4 | Status: [ Draft | Accepted | Installed | Voting | Deferred | Rejected | Superseded | Obsoleted ] 5 | Replaces: (optional) 6 | Obsoleted-By: (optional) 7 | Superseded-By: (optional) 8 | Type: [ Informational | Protocol ] 9 | Created: 10 | Discussion: 11 | Worker: (optional) 12 | 13 | # Abstract 14 | # Motivation 15 | # Rational 16 | # Specifications 17 | # Discussion 18 | # Summary for Shareholders 19 | # Copyright 20 | # See Also 21 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # BitShares Improvement Proposal 2 | 3 | BSIP stands for BitShares Improvement Proposal. A BSIP is a design document 4 | providing information to the BitShares community, or describing a new feature for 5 | BitShares or its processes or environment. BSIPs provide a concise 6 | technical specification of features and a rationale for them. 7 | 8 | The distinct document [BSIP Purpose and Guidelines](bsip-0001.md) gives a more 9 | detailed explanation. 10 | 11 | # Available BSIPs 12 | 13 | Number | Title | Owner | Type | Status 14 | -------------------|----------------------------------------------------------|-------------------|----------------|-------- 15 | [1](bsip-0001.md) | BSIP Purpose and Guidelines | Fabian Schuh | Informational | Draft 16 | [2](bsip-0002.md) | Refund Create Order Fees on Cancel | Daniel Larimer | Protocol | Superseded by [26](bsip-0026.md) 17 | [3](bsip-0003.md) | Maker / Taker Market Fees Flag | Daniel Larimer | Protocol | Obsoleted by [81](bsip-0081.md) 18 | [4](bsip-0004.md) | Distribute Market Fees on Core Asset to Referral Program | Daniel Larimer | Protocol | Obsoleted by [43](bsip-0043.md) 19 | [5](bsip-0005.md) | Expiring Votes for Witnesses | Daniel Larimer | Protocol | Superseded by [22](bsip-0022.md) 20 | [6](bsip-0006.md) | Market Maker Incentivization | Daniel Larimer | Protocol | Draft 21 | [7](bsip-0007.md) | Fee Backed Assets (FBA) | Daniel Larimer | Protocol | Installed 22 | [8](bsip-0008.md) | Privacy (STEALTH) Mode | Daniel Larimer | Protocol | Installed 23 | [9](bsip-0009.md) | Benefit Society | Fabian Schuh | Protocol | Draft 24 | [10](bsip-0010.md) | Percentage-based transfer fee solution based on CER | Jakub Zarembinski | Protocol | Accepted 25 | [15](bsip-0015.md) | Disable negative voting on workers | Daniel Larimer | Protocol | Installed 26 | [16](bsip-0016.md) | Optimization to Force Settlement Parameters of BitCNY | Jerry Liu | Protocol | Installed 27 | [17](bsip-0017.md) | Revive BitAsset after Global Settlement | Peter Conrad | Protocol | Draft 28 | [18](bsip-0018.md) | Revive BitAsset through buying Settlement Pool | Fabian Schuh | Protocol | Installed 29 | [19](bsip-0019.md) | Introducing profit sharing/dividends to Bitshares (MPA only) | Customminer | Protocol | Deferred 30 | [20](bsip-0020.md) | Introducing profit sharing/dividends to Bitshares (UIA only) | Customminer | Protocol | Deferred 31 | [21](bsip-0021.md) | Introducing the 'Coin-Age' statistic to Bitshares assets | Customminer | Protocol | Draft 32 | [22](bsip-0022.md) | Vote Decay for Witnesses, Committee Members & Proxies | Customminer | Protocol | Draft 33 | [23](bsip-0023.md) | Sharedropping an UIA against an external cryptocurrency distribution snapshot | Customminer | Protocol | Draft 34 | [24](bsip-0024.md) | Locking Bitshares away as 'Bitshares Influence' for voting privileges on the BTS DEX | Customminer | Protocol | Draft 35 | [25](bsip-0025.md) | Transaction Flat-Rates with Weighted Rate-Limitation | Fabian Schuh | Protocol | Draft 36 | [26](bsip-0026.md) | Refund Order Creation Fee in Originally Paid Asset on Cancel | Abit More | Protocol | Installed 37 | [27](bsip-0027.md) | Asset Issuer Reclaim Fee Pool Funds | Abit More | Protocol | Installed 38 | [28](bsip-0028.md) | Worker Proposal Improvements | Bill Butler | Protocol | Draft 39 | [29](bsip-0029.md) | Asset issuer change to require owner authority | Fabian Schuh | Protocol | Installed 40 | [30](bsip-0030.md) | Always Allow Increasing Collateral Ratio If Debt Not Increased | Abit More | Protocol | Installed 41 | [31](bsip-0031.md) | Update Short Position's Margin Call Price After Partially Called Or Settled | Abit More | Protocol | Installed 42 | [32](bsip-0032.md) | Always Match Orders At Maker Price | Abit More | Protocol | Installed 43 | [33](bsip-0033.md) | Maker Orders With Better Prices Take Precedence | Abit More | Protocol | Installed 44 | [34](bsip-0034.md) | Always Trigger Margin Call When Call Price Above Or At Price Feed | Abit More | Protocol | Installed 45 | [35](bsip-0035.md) | Mitigate Rounding Issue On Order Matching | Abit More | Protocol | Installed 46 | [36](bsip-0036.md) | Remove expired price feeds on maintenance interval | oxarbitrage | Protocol | Installed 47 | [37](bsip-0037.md) | Allow new asset name to end with a number | oxarbitrage | Protocol | Installed 48 | [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed 49 | [39](bsip-0039.md) | Automatically approve proposals by the proposer | Fabian Schuh | Protocol | Draft 50 | [40](bsip-0040.md) | Custom active permission | Stefan Schießl | Protocol | Accepted - Milestone 1 51 | [41](bsip-0041.md) | Reduce MSSR of bitCNY from 1.1 to 1.05 | Jerry Liu | Informational | Superseded by [59](bsip-0059.md) 52 | [42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Rejected 53 | [43](bsip-0043.md) | Market Fee Sharing | OpenLedgerApp | Protocol | Installed 54 | [44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Installed 55 | [45](bsip-0045.md) | Add bitAsset Backing Collateral flag/permission | Customminer | Protocol | Draft 56 | [46](https://github.com/bitshares/bsips/pull/111) | Escrow Concepts | Taconator | Informational | Accepted 57 | [47](bsip-0047.md) | Vote Proxies for Different Referendum Categories and explicit voting operation | Fabian Schuh | Protocol | Draft 58 | [48](https://github.com/bitshares/bsips/pull/115) | Add Flag to Asset to Prevent Manipulating Max Supply | Fabian Schuh | Protocol | Draft 59 | [50](https://github.com/bitshares/bsips/issues/88) | Stealth development, Phase II | Chris Sanborn | Informational | Draft 60 | [51](https://github.com/bitshares/bsips/issues/89) | New operations for Confidential Asset (CA) transactions | Chris Sanborn | Protocol | Draft 61 | [52](https://github.com/bitshares/bsips/issues/90) | Ring signatures for untraceability of Stealth transactions | Chris Sanborn | Protocol | Draft 62 | [53](https://github.com/bitshares/bsips/pull/116) | Blockchain scanning for inbound Stealth transactions | Chris Sanborn | Informational (Client Protocol) | Draft 63 | [54](https://github.com/bitshares/bsips/issues/92) | Deterministic addresses for Stealth wallets | Chris Sanborn | Informational | Draft 64 | [55](https://github.com/bitshares/bsips/issues/93) | Metadata hiding via Garlic Routing and other means | Chris Sanborn | Informational | Draft 65 | [57](bsip-0057.md) | Managed Vesting Balances | Blockchain Projects BV | Protocol | Draft 66 | [58](bsip-0058.md) | Global Settlement Protection Through Price Feeding | Jerry Liu | Informational | Accepted 67 | [59](bsip-0059.md) | Adjustment of MSSR and MCR Through Voting | Jerry Liu | Informational | Accepted 68 | [60](bsip-0060.md) | BitShares URI scheme | John Titor, Stefan Schießl, Abit More | Informational (Client Protocol) | Accepted 69 | [61](bsip-0061.md) | Operation to Update Limit Orders | Nathan Hourt | Protocol | Draft 70 | [62](bsip-0062.md) | Close Short Position | Stefan Schießl | Protocol | Approved 71 | [63](bsip-0063.md) | Short-lived Unidirectional Payment Channels | Christopher J. Sanborn | Informational | Draft 72 | [64](bsip-0064.md) | Optional HTLC preimage length, HASH160 addition, and memo field | John Jones, Abit More | Protocol | Installed 73 | [65](https://github.com/bitshares/bsips/pull/149) | Fix Locked Accounts | OpenLedger | Protocol | Draft 74 | [66](https://github.com/bitshares/bsips/pull/132) | Sharedrop Operation | OpenLedger | Protocol | Draft 75 | [67](https://github.com/bitshares/bsips/pull/133) | Dynamic Market Fees | OpenLedger | Protocol | Draft 76 | [68](https://github.com/bitshares/bsips/pull/134) | Market Fee Based Asset | OpenLedger | Protocol | Draft 77 | [69](bsip-0069.md) | Additional Assert Predicates | Christopher J. Sanborn | Protocol | Draft 78 | [70](bsip-0070.md) | Peer-to-Peer Leveraged Trading | George Harrap, Michel Santos, Peter Conrad | Protocol | Draft 79 | [71](bsip-0071.md) | Add "Prevent Global Settlement" Flag for Smartcoin | Jerry Liu | Protocol | Draft 80 | [72](bsip-0072.md) | Tanks and Taps: A General Solution for Smart Contract Asset Handling | Nathan Hourt | Protocol | Draft 81 | [73](bsip-0073.md) | Match Force-Settlement Orders with Margin Calls and Limit Orders | Abit More | Protocol | Draft 82 | [74](bsip-0074.md) | Margin Call Fee Ratio | Jerry Liu | Protocol | Installed 83 | [75](bsip-0075.md) | Asset Owner Defines MCR and MSSR Values | John Jones | Protocol | Installed 84 | [76](bsip-0076.md) | Committee-Defined SmartAsset Collateral Threshold | Abit More | Informational | Draft 85 | [77](bsip-0077.md) | Require Higher CR When Creating / Adjusting Debt Positions | Abit More | Protocol | Installed 86 | [81](bsip-0081.md) | Simple Maker-Taker Market Fees | Abit More | Protocol | Installed 87 | [84](bsip-0084.md) | Elections Based on non-Core Asset | Peter Conrad | Protocol | Draft 88 | [85](bsip-0085.md) | Maker Order Creation Fee Discount | Abit More | Protocol | Installed 89 | [86](bsip-0086.md) | Share market fees to the network | Abit More | Protocol | Installed 90 | [87](bsip-0087.md) | Force Settlement Fee | Jerry Liu | Protocol | Installed 91 | 92 | 93 | -------------------------------------------------------------------------------- /bsip-0001.md: -------------------------------------------------------------------------------- 1 | BSIP: 0001 2 | Title: BSIP Purpose and Guidelines 3 | Authors: Fabian Schuh 4 | Status: Draft 5 | Type: Informational 6 | Created: 2015-12-16 7 | 8 | # What is a BSIP? 9 | 10 | BSIP stands for BitShares Improvement Proposal but can also seen as an 11 | improvement *protocol*. A BSIP is a design document providing information to the 12 | BitShares community, or describing a new feature for BitShares or its processes 13 | or environment. The BSIP should provide a concise technical specification of the 14 | feature or the idea and a rationale for it. It may not only describe technical 15 | improvements but also document *best-practises* and recommendations. 16 | 17 | We intend BSIPs to be the primary mechanisms for proposing new features, for 18 | collecting community input on an issue, and for documenting the design decisions 19 | that have gone into BitShares. The BSIP author is responsible for building 20 | consensus within the community and documenting dissenting opinions. 21 | 22 | Because the BSIPs are maintained as text files in a versioned repository, their 23 | revision history is the historical record of the feature proposal. 24 | 25 | # BSIP Types 26 | 27 | There are two kinds of BSIPs: 28 | 29 | * An **Informational** BSIP describes a BitShares design issue, or provides general 30 | guidelines or information to the BitShares community, but does not propose a 31 | new feature, protocol change or any other modification. Informational BSIPs do 32 | not necessarily represent a BitShares community consensus or recommendation, 33 | so users and implementors are free to ignore Informational BSIPs or follow 34 | their advice. Examples would be *best-practises* or *recommendations*. 35 | * A **Protocol** Upgrade BSIP describes any change that affects most or all 36 | BitShares implementations, such as a change to the protocol, a change in block 37 | or transaction validity rules, or any change or addition that affects the 38 | interoperability of applications using BitShares. 39 | 40 | # Contributing 41 | 42 | People wishing to submit BSIPs first should propose their idea as github 43 | issue first. After discussion you will be assigned a number for the bsip 44 | and can send a pull request for your *draft*. Once consensus among 45 | discussion participants is reached, the status can be switched to 46 | *accepted*. From this time on, major changes of the document will not be 47 | permitted. 48 | 49 | If the proposal requires a protocol upgrade, the proposal is considered 50 | *implemented* only if shareholders have approved a corresponding worker or 51 | hard fork proposal. Informational BSIPs can only reach the *accepted* 52 | state since their implementation is not enforced by the blockchain. 53 | 54 | We are fairly liberal with listing BSIP drafts here since the 55 | final decision of its actual implementation is made solely by BitShares 56 | shareholders via approval voting. 57 | 58 | It is highly recommended that a single BSIP contain a single key 59 | proposal or new idea. Small enhancements or patches often don't need a 60 | BSIP and can be injected into the BitShares development work flow with a 61 | patch submission to the BitShares issue tracker. The more focused the 62 | BSIP, the more successful it tends to be. The BSIP editor reserves the 63 | right to reject BSIP proposals if they appear too unfocused or too 64 | broad. If in doubt, split your BSIP into several well-focused ones. 65 | 66 | Vetting an idea publicly before going as far as writing a BSIP is meant to save 67 | the potential author time. Many ideas have been brought forward for changing 68 | BitShares that have been rejected for various reasons. Asking the BitShares 69 | community first if an idea is original helps prevent too much time being spent 70 | on something that is guaranteed to be rejected based on prior discussions 71 | (searching the internet does not always do the trick). It also helps to make 72 | sure the idea is applicable to the entire community and not just the author. 73 | Just because an idea sounds good to the author does not mean it will work for 74 | most people in most areas where BitShares is used. 75 | 76 | Following a discussion, the proposal should be sent to the BitShares developers 77 | and the BSIP editors with the draft BSIP. This draft must be written in BSIP 78 | style as described below, else it will be sent back without further regard until 79 | proper formatting rules are followed. 80 | 81 | If the BSIP editor approves, he will assign the BSIP a number, label it, give it 82 | status "Draft", and add it to the git repository. The BSIP editor will not 83 | unreasonably deny a BSIP. Reasons for denying BSIP status include duplication 84 | of effort, being technically unsound, not providing proper motivation or 85 | addressing backwards compatibility, or not in keeping with the BitShares 86 | philosophy. 87 | 88 | The BSIP author may update the Draft as necessary in the git repository. Updates 89 | to drafts may also be submitted by the author as pull requests. 90 | 91 | For a BSIP to be accepted it must meet certain minimum criteria. It must be a 92 | clear and complete description of the proposed enhancement. The enhancement must 93 | represent a net improvement. The proposed implementation, if applicable, must be 94 | solid and must not complicate the protocol unduly. 95 | 96 | Once a BSIP has been published, the reference implementation must be 97 | completed. When the reference implementation is complete and accepted 98 | by the shareholders via approval voting, the status will be changed to 99 | "Accepted". A BSIP can also be "Rejected" by shareholders. 100 | 101 | Furthermore, a BSIP can be assigned status "Deferred". The BSIP author or editor 102 | can assign the BSIP this status when no progress is being made on the BSIP. Once 103 | a BSIP is deferred, the BSIP editor can re-assign it to draft status. 104 | 105 | BSIPs can also be superseded by a different BSIP, rendering the original 106 | obsolete. This is intended for Informational BSIPs, where version 2 of an API 107 | can replace version 1. 108 | 109 | # What belongs in a BSIP? 110 | 111 | Each BSIP *should* have the following parts: 112 | 113 | * Preamble -- RFC 822 style headers containing meta-data about the BSIP, 114 | including the BSIP number, a short descriptive title (limited to a maximum of 115 | 44 characters), the names, and optionally the contact info for each author, 116 | etc. 117 | 118 | * Abstract -- a short (~200 word) description of the technical issue being 119 | addressed. 120 | 121 | * Copyright/public domain -- Each BSIP must either be explicitly labelled as 122 | placed in the public domain (see this BSIP as an example) or licensed under 123 | the Open Publication License. 124 | 125 | * Motivation -- The motivation is critical for BSIPs that want to change the 126 | BitShares protocol. It should clearly explain why the existing protocol 127 | specification is inadequate to address the problem that the BSIP solves. BSIP 128 | submissions without sufficient motivation may be rejected outright. 129 | 130 | * Rationale -- The rationale fleshes out the specification by describing what 131 | motivated the design and why particular design decisions were made. It should 132 | describe alternate designs that were considered and related work, e.g. how the 133 | feature is supported in other languages. The rationale should provide evidence 134 | of consensus within the community and discuss important objections or concerns 135 | raised during discussion. 136 | 137 | * Specification -- The technical specification should describe the syntax and 138 | semantics of any new feature. The specification should be detailed enough to 139 | allow competing, interoperable implementations for any of the current 140 | BitShares platforms. 141 | 142 | * Discussion -- The BSIP shall include a discussion on positive and negative 143 | effects on the BitShares ecosystem shall it be accepted by shareholders. This 144 | section is supposed to be the most important section for shareholders to grasp 145 | the full impact of the BSIP and help shareholders to make a decision. 146 | 147 | * Summary for Shareholders -- Most BSIPs will probably be of technical nature. 148 | However, many shareholders are not as technical as the author of a particular 149 | BSIP. This non-technical paragraph serves as a place which can be used to 150 | to interact with shareholders and help them form their opinion. It is not 151 | meant to be a marketing driven paragraph to convince shareholders to vote 152 | **for** or **against** a proposal, though. 153 | 154 | # BSIP Formats and Templates 155 | 156 | BSIPs should be written in mediawiki or markdown format. Image files should be 157 | included in a subdirectory for that BSIP. A template including the header 158 | preamble is provided in [this repository](BSIPs-Template.md). 159 | 160 | # BSIP Editors 161 | 162 | The current BSIP editors are: 163 | 164 | * Fabian Schuh 165 | * Sigve Kvalsvik 166 | * *cass* 167 | 168 | The editors don't pass judgement on BSIPs. We merely do the administrative & 169 | editorial part. 170 | 171 | Many BSIPs are written and maintained by developers with write access to the 172 | BitShares codebase. The BSIP editors monitor BSIP changes, and correct any 173 | structure, grammar, spelling, or markup mistakes we see. 174 | 175 | For each new BSIP that comes in an editor does the following: 176 | 177 | * Read the BSIP to check if it is ready: sound and complete. The ideas must make 178 | technical sense, even if they don't seem likely to be accepted. 179 | * The title should accurately describe the content. 180 | * Edit the BSIP for language (spelling, grammar, sentence structure, etc.), 181 | markup (for reST BSIPs), code style (examples should match BSIP 8 & 7). 182 | 183 | Once the BSIP is ready for the repository it should be submitted as a "pull 184 | request" to the [https://github.com/BitShares/bsips BitShares/BSIPs] repository 185 | on GitHub where it may get further feedback. 186 | 187 | The BSIP editor will: 188 | 189 | * Assign a BSIP number (almost always just the next available number, but 190 | sometimes it's a special/joke number, like 666 or 3141) in the pull request 191 | comments. 192 | * Merge the pull request when the author is ready (allowing some time for 193 | further peer review). 194 | * List the BSIP in [[README.mediawiki]] 195 | * Send email back to the BSIP author with next steps (post to BitShares mailing 196 | list). 197 | 198 | # History 199 | 200 | This document was derived heavily from Python's PEP-0001 and Bitcoin BIP-0001. 201 | In many places text was simply copied and modified. Although the 202 | PEP-0001/BIP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David 203 | Goodger, they are not responsible for its use in the BitShares Improvement 204 | Process, and should not be bothered with technical questions specific to 205 | BitShares or the BSIP process. Please direct all comments to the BSIP editors 206 | or the BitShares development mailing list. 207 | -------------------------------------------------------------------------------- /bsip-0002.md: -------------------------------------------------------------------------------- 1 | BSIP: 0002 2 | Title: Refund Create Order Fees on Cancel 3 | Authors: Daniel Larimer 4 | Fabian Schuh 5 | Status: Superseded 6 | Type: Protocol 7 | Created: 2015-12-16 8 | Discussion: 9 | 10 | Superseded-By: [26](bsip-0026.md) 11 | Worker: 1.14.7 12 | 13 | # Abstract 14 | 15 | To make the BitShares decentralized exchanges more similar to other exchanges 16 | there should be no fee for creating orders that do not get filled. 17 | Unfortunately, to prevent abuse, a minimum fee is still necessary. 18 | 19 | # Specifications 20 | 21 | This proposal will charge the minimum order fee at the time the order is 22 | created. It will be refunded if the order is canceled before any part of the 23 | order is filled. A small fee will be charged to cancel orders. This order 24 | cancellation fee will be just enough to prevent spam (equivalent of a fraction 25 | of a Dollar cent). 26 | 27 | If the fee is paid in something other than BTS, it will be converted to BTS via 28 | the fee pool at the time the order is placed. If the order is canceled, BTS will 29 | be refunded to the user's account. 30 | 31 | Recommended Order Creation Fee: $0.20 for normal users $0.04 for LTM Recommended 32 | Order Cancelation Fee: $0.01 for normal users, $0.002 for LTM 33 | 34 | As a result, the minimum market fees for normal users will be less than those of 35 | centralized exchanges for orders greater than $100. For lifetime members, orders 36 | above $20 will be cheaper than the 0.2% fee charged by normal exchanges. 37 | 38 | # Discussion 39 | 40 | ## Fees payed in BTS 41 | 42 | Paying fees in BTS is the cheapest way to pay fees because the 43 | core-exchange-rate for UIA usually charge a slight premium to handle market 44 | risk. This means that the next order you place will use the BTS to pay the fee 45 | rather than the user asset. Think about it as getting a refund in "store 46 | credit". If you place an order, cancel an order and then decide you don't want 47 | to do any more business with BitShares then you will have to sell the BTS (which 48 | will require placing an order) or "transferring". 49 | 50 | Stated another way, for trading bots it doesn't matter that the refund is in a 51 | different asset. For users it doesn't matter either. It will only impact those 52 | who attempt to flood with a lot of orders, then cancel all of them. They will 53 | end up converting their UIA to BTS at poor exchange rates and then having to 54 | sell the BTS. 55 | 56 | Bottom line, we presume someone placing an order will eventually want it filled. 57 | By refunding them in BTS they can eventually get it filled and end up with 0 58 | BTS. 59 | 60 | ## Discouraging of Makers when not Refunding Partially Filled Orders 61 | 62 | A concern is that the rule may encourage taker but discourage maker, as if an 63 | order is partly filled, the creation fee will not be refunded, and obviously 64 | taker can be more easily to make sure his order is fully, not partly filled. 65 | 66 | ## Anti-Spam considerations 67 | 68 | Furthermore, a fee has to be charged for anti-spam. Orders create objects which 69 | must be kept in memory which imposes a resource cost on every node on the 70 | network (plus more cost for storage / bandwidth for the transaction). Cancelling 71 | an order frees up memory, which can be viewed as a negative resource cost, 72 | represented by the refunded fee. 73 | 74 | Ultimately, this reflects a tension between the economic value of liquidity 75 | (market makers should be encouraged because a bigger book is better) and its 76 | cost (every order consumes memory). If we make the fee equal to cost, someone 77 | deciding whether to place an order can determine whether the cost exceeds the 78 | value, and the tension is resolved in a decentralized market-based way. 79 | 80 | # Copyright 81 | 82 | This document is placed in the public domain. 83 | -------------------------------------------------------------------------------- /bsip-0003.md: -------------------------------------------------------------------------------- 1 | BSIP: 0003 2 | Title: Maker / Taker Market Fees Flag 3 | Authors: Daniel Larimer 4 | Fabian Schuh 5 | Status: Obsoleted 6 | Obsoleted-By: 0081 7 | Type: Protocol 8 | Created: 2015-12-16 9 | Discussion: https://github.com/cryptonomex/graphene/issues/468 10 | Worker: not available yet 11 | 12 | # Abstract 13 | 14 | Under this proposal, an asset issuer could enable a flag on their asset that 15 | would not charge any market fees for open orders. The market fee would only be 16 | charged to the taker (the individual whose new order is actively being matched). 17 | 18 | # Motivation 19 | 20 | This would incentivise people to leave orders on the books (it is cheaper). The 21 | only person who would pay a fee would be the one who wants immediate liquidity. 22 | 23 | # Specifications 24 | 25 | # Discussion 26 | 27 | Since this feature does nothing unless the asset issuer updates the asset flags 28 | to enable this feature, we can leave it to the committee to decide (as this is a 29 | fee related question). In this way the community (via committee) has control. 30 | 31 | # Copyright 32 | 33 | This document is placed in the public domain. 34 | -------------------------------------------------------------------------------- /bsip-0004.md: -------------------------------------------------------------------------------- 1 | BSIP: 0004 2 | Title: Distribute Market Fees on Core Asset to Referral Program 3 | Authors: Daniel Larimer 4 | Fabian Schuh 5 | Status: Obsoleted by [BSIP-0043](bsip-0043.md) 6 | Type: Protocol 7 | Created: 2015-12-16 8 | Discussion: 9 | Worker: TBD 10 | 11 | # Abstract 12 | 13 | Currently the BitShares network does not charge a percentage based market fee on 14 | trades of the core asset (BTS) or assets created by the committee account 15 | (BitAssets like USD, CNY, etc). Instead BitShares has a fixed price for filled 16 | orders defined by the order creation fee. See [BSIP-0002](bsip-0002.md) for more 17 | information. 18 | 19 | This proposal is to implement a hard-fork that would grant committee members the 20 | option to charge market fees for their assets. Any market fees earned would be 21 | converted to BTS via the fee pool and then distributed to the referral program 22 | like any other fees. 23 | 24 | # Motivation 25 | 26 | Market pegged assets trade at 0% market fees by default. The commitee members 27 | could decide to set a percentage as fee already, but the fees would end up in 28 | the committee's account. 29 | 30 | By implementing this proposals, we let shareholders decide whether or not to 31 | redirect these profits to the referral program. 32 | 33 | # Discussion 34 | 35 | When enabling market fees for an asset, trading becomes slightly more expensive 36 | for traders and could discourage trades. On the other hand, having more funds 37 | to distribute for marketing in the form of referral rewards could improve 38 | exposure and incentivise to bring in new customers for our products and the 39 | trading platform which may result in increased profits from fees in general. 40 | Furthermore, if percentage-based market fees were enabled now, they would end up 41 | in the issuers account, i.e. the committee-account, and could potentially be 42 | used by the committee to serve BitShares directly. By approving this proposal, 43 | those funds were distributed to the referral program which could improve 44 | adoption. 45 | 46 | # UIA vs Committee Asset 47 | 48 | When trading between two assets controlled by the committee it goes to the referral program, 49 | when trading between a UIA and an asset controlled by the committee the fee should go to the UIA issuer. 50 | In this way asset issuers get the same income they would get if they traded BTS vs an asset on their 51 | local exchange. 52 | 53 | # Copyright 54 | 55 | This document is placed in the public domain. 56 | -------------------------------------------------------------------------------- /bsip-0005.md: -------------------------------------------------------------------------------- 1 | BSIP: 0005 2 | Title: Expiring Votes for Witnesses 3 | Authors: Daniel Larmier 4 | Fabian Schuh 5 | Status: Superseded 6 | Superseded-By: 0022 7 | Type: Protocol 8 | Created: 2015-12-16 9 | Discussion: 10 | 11 | Worker: tbd 12 | 13 | # Abstract 14 | 15 | Votes for witnesses are a measure of reputation in that they cast a persistent 16 | opinion - so not like votes in the traditional sense of the word. The 17 | witness voting system is currently designed to ensure stability by directing 18 | the apathetic to vote for incumbents. Whilst this may have advantages, it 19 | seems to present the danger that incumbents are likely to attain a 20 | near-unassailable position (excepting of course those who exhibit negligent/bad 21 | behaviour). 22 | 23 | # Motivation 24 | 25 | If the aim is the create an autocracy - albeit seeded by the active witnesses 26 | or so original gainers of significant 'reputation' - then this is fine. However, 27 | it would seem to discourage serious efforts to try and break into the active 28 | circle by newcomers with much to contribute. At the end of the BitShares 1 29 | network, circa. 220M votes were required and a quick browse of the delegates 30 | showed that with a few notable exceptions, the majority have been in place since 31 | a 4 or 5 digit block number - have all been of these current, active contributors? 32 | 33 | # Specifications 34 | 35 | A blockchain parameter can be added that enforces a minimal *freshness* to votes 36 | that are counted and handle cases of lost keys or apathetic votes hanging 37 | around. 38 | 39 | # Discussion 40 | 41 | ## Linear, Exponential, or other decay 42 | 43 | The question is left open whether the *freshness* of votes decreases linearily, 44 | exponentially or by any other function. It is further not defined if the 45 | decrease should scale with the number of blocks or the absolute time. 46 | 47 | ## Voter Apathy 48 | 49 | The argument has been raised that a apathy of voters would result in only few 50 | *active* votes which could leave the blockchain open to attacks with only little 51 | stake. 52 | 53 | ## Highly Volatile Voting Power 54 | 55 | This proposal results in a high volatilty in voting power which has mostly 56 | negative effects when votes are removed from the actively voting stake, i.e. a 57 | big stake (e.g. from a proxy) expires. This could result in significant changes 58 | that take effect instantly. 59 | An alternative approach to fix this would be to have a window (e.g. several 60 | days) in which changes in votes take effect gradually. 61 | 62 | # Copyright 63 | 64 | This document is placed in the public domain. 65 | 66 | # See Also 67 | 68 | * https://bitsharestalk.org/index.php/topic,20753.0.html 69 | -------------------------------------------------------------------------------- /bsip-0007.md: -------------------------------------------------------------------------------- 1 | BSIP: 0007 2 | Title: Fee Backed Assets 3 | Authors: Danial Larimer 4 | Stan Larimer 5 | Fabian Schuh 6 | Status: Installed 7 | Type: Protocol 8 | Created: 2015-12-16 9 | Discussion: 10 | Worker: not applicable 11 | 12 | # Abstract 13 | 14 | Existing core features of the BitShares protocol are Market Pegged Assets (MPA) 15 | and issuer backed User Issued Assets (UIA). In this proposal, we introduce 16 | another type of asset: *Fee Backed Assets (FBA)*. 17 | 18 | Feed backed assets allow to propose and fund *market based* innovation by 19 | sharing a cut of future profits generated by this particular innovation with the 20 | people that helped fund it. Think of it as a *Kickstarter* for features. 21 | Hence, if people can profit from successful features in the form of fees then it 22 | can help the BitShares ecosystem to become more adaptable over time as it 23 | promotes innovation and can pay for its development. 24 | 25 | # Motivation 26 | 27 | Let's assume a developer installs a new function into the BitShares protocol 28 | that charges fees for its service. Where should those fees go? To the developer? 29 | To the share holders? How should a decision be made? Why would share holders vote 30 | to fund a feature if they can't profit from it? 31 | 32 | The answer is to pay the profits from fees generated by the feature to holders 33 | of a UIA that has been created for that purpose, specifically. In other words: 34 | owners of that UIA own a portion of those revenue producing assets. This revenue 35 | generating counterparty free asset is backed solely by the blockchain and its 36 | user base and can be sold freely on the decentralized market. 37 | 38 | Since they have no counterparty, they are **not a security**. They are simply 39 | capital equipment, like selling a mining machine. 40 | 41 | This new kind of digital asset trades like any of the others but has fascinating 42 | new properties. 43 | 44 | For every new revenue generting innovation or feature in the whole ecosystem, 45 | there can be a new fee backed asset. Developers recoup their costs by selling 46 | (or pre-selling) these revenue generating software devices (or keeping them to 47 | earn the revenue they produce.) 48 | 49 | # Examples 50 | 51 | ## Taxi Rental 52 | 53 | Let's assume we build 100 robotic software taxi cabs that deliver private 54 | packages for hire. Program them via blockchain logic to take turns delivering 55 | packages. Sell the cabs to the network in exchange for a set of tickets good for 56 | rental minutes on a cab. Now we can resell or trade of those tickets on the open 57 | market. This way, anyone can rent time on any of the limited supply of "cabs" 58 | and earn fees for performing delivery services. 59 | 60 | The `TAXI` FPA could represent all available minutes on a network-owned fleet of 61 | robotic taxi cabs. Buy up as many minutes of their time as you want and you have 62 | your own revenue generating business with no counter parties. 63 | 64 | ## Project/Feature Funding 65 | 66 | In the case of the [Privacy Mode](bsip-0008.md), the project development can be 67 | funded by a PRIVACY FPA that gets their owners a cut of fees produced by 68 | transactions using that feature in the future. Every BitShares customer that 69 | wants to gain advantages of that Privacy Mode needs to pay an increased fee for 70 | its service. These fees are distributed among all owners of the `STEALTH` asset. 71 | 72 | # Regulatory Issues 73 | 74 | One of the first and thorniest problems we tackled is the nasty fact of 75 | *Regulatory Risk*. There exists a vocal contingent of people who want very much 76 | that an FBA (fee based asset) be created to fund a feature upgrade to the 77 | BitShares blockchain. They want that everyone be thus enabled an opportunity to 78 | participate in the fee stream originating from future use of the feature by 79 | purchasing shares of a FBA. 80 | 81 | The conundrum is that whoever creates the FBA and offers it to the public as a 82 | means of participation in a fee-based income stream faces a risk of coming under 83 | regulatory scrutiny if the project is a success (e.g. Satoshi Dice) or even if 84 | it is not a success (through some disgruntled investor complaining to a 85 | regulatory authority). For a more in depth look in to Regulatory Risk please see 86 | [1,2]. 87 | 88 | If something falls within the definition of a *security* under applicable law, 89 | it will be governed by extensive rules and regulations that can be quite complex 90 | and expensive to comply with. And subject the issuer to a large fine/other 91 | penalties if not complied with! 92 | 93 | Once [BSIP-0008](bsip-0008.md) has been implemented and is available on the 94 | blockchain (but not before), it will be possible for future investor and 95 | entrepreneurs to create FBAs and crowd fund new features by having a *Private 96 | Mode account* ([BSIP-0008](bsip-0008.md)), issue the FBA from an *unknown* 97 | jurisdiction that is presumably not subject to securities concerns. 98 | 99 | # Specifications 100 | 101 | Since every innovation on the blockchain level has to come with a protocol 102 | upgrade (previsouly denoted as a *hard fork*), the upgrade also comes with a so 103 | called *management account* that is specific for this specific innovation or 104 | feature. For regulatory reasons, the blockchain itself is seen as the creator of 105 | the asset and has the sole permission to issue new shares. 106 | 107 | The initial share holders of the FBA asset have to be defined upon the hard fork 108 | by the developers of the feature. It is left to the developers of the innovation 109 | to derive a proper scheme to identify the initial share holders. 110 | 111 | Most importantly, the management account will have a Multi-Signature authority 112 | assigned to the `X` largest share holders of that account weighted proportional 113 | to stake and will have the power to set the fee. 114 | 115 | # Discussion 116 | 117 | Daniel Larimer: I would say that far more than Worker Proposals or anything 118 | else, the Fee Backed Assets is incentivizing entrepreneurs to come up with 119 | ideas, come up with features and then go and fund them and make it happen. 120 | 121 | This proposal helps fund new features and innovations without the need to dilute 122 | BitShares to pay for its developments. However, having the features transaction 123 | fees be paid to the holders of the corresponding FBA results in a reduced 124 | revenue for BitShares holders, which is only fair since they haven't funded the 125 | feature. However, the infrastructure is still provided by BitShares and as such 126 | a cut of the features transaction fees may be directed to the BitShares holders 127 | by burning or reserving in the reserve funds. 128 | 129 | The developer of a FBA-supported innovation can chose a mixed funding model and 130 | make use of a worker to fund parts of the development. As a consequence a 131 | higher percentage of the transcaction fees should be directed towards the 132 | BitShares holders. 133 | 134 | # Copyright 135 | 136 | This document is placed in the public domain. 137 | 138 | # See Also 139 | 140 | * [1] https://bitsharestalk.org/index.php/topic,20499.msg264752.html#msg264752 141 | * [2] http://www.cuttingedgecapital.com/what-is-a-security-and-why-does-it-matter/ 142 | -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-0.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-1.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-2.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-3.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-4.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-5.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-6.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-7.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup-8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup-8.png -------------------------------------------------------------------------------- /bsip-0008/gui-mockup.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0008/gui-mockup.pdf -------------------------------------------------------------------------------- /bsip-0009/fee-dist.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0009/fee-dist.png -------------------------------------------------------------------------------- /bsip-0009/karma-exit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0009/karma-exit.png -------------------------------------------------------------------------------- /bsip-0009/karma.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0009/karma.png -------------------------------------------------------------------------------- /bsip-0015.md: -------------------------------------------------------------------------------- 1 | BSIP: 13 2 | Title: Disable negative voting on workers 3 | Authors: Daniel Larimer 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2015-03-09 7 | Discussion: https://github.com/cryptonomex/graphene/issues/607 8 | https://github.com/cryptonomex/graphene/issues/565 9 | 10 | # Abstract 11 | 12 | This proposal fixes a potential attack vector that might be exploited by rich shareholders that hold more collective voting power than the last approved worker (usually a refund/burn worker). 13 | 14 | # Motivation 15 | 16 | A whale of a group of whales can take funds from the reserve pool by creating a worker and instantly approve it with his stake. Shareholders and proxies can disapprove the new worker but only have a small time-window before the attacker makes a profit. 17 | 18 | # Rational 19 | 20 | Pro-active downvoting is a losing proposition. An attacker can create 1000 workers and the network will not allow you to down-vote so many workers. The only real solution is to *upvote* refund workers or removing DOWNVOTING is the actual solution to this attack. 21 | 22 | Since upvoting of refund workers results in a higher barrier of entry for new legit workers, the solution proposed here is to remove down voting entirely. 23 | 24 | Furthermore, a negative vote is equivalent with upvoting all alternatives and results in slightly narrower gaps between votes. It compares pretty will with comparing -1 with +1 (currently) and 0 with +1 as in this proposal. 25 | 26 | # Specifications 27 | 28 | This proposal could be implemented by removing the ability to cast negative votes or by not taking negative votes into consideration during vote counting in the maintenance interval. 29 | 30 | # Copyright 31 | 32 | This document is placed in the public domain. 33 | -------------------------------------------------------------------------------- /bsip-0016.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BSIP: 0016 3 | Title: Optimization to Force Settlement Parameters of BitCNY 4 | Authors: Jerry Liu 5 | Status: Installed 6 | Type: Protocol 7 | Created: 2016-05-06 8 | Discussion: https://bitsharestalk.org/index.php/topic,22355.0.html 9 | Worker: no 10 | ``` 11 | 12 | # Abstract 13 | 14 | We here propose to optimize the settlement *offset* and maximum settlement *volume* of bitCNY to encourage shorters to provide liquidity in the bitCNY:BTS market with a lower risk. 15 | 16 | # Motivation 17 | 18 | As a smartcoin, bitCNY pegs to CNY, it is expected to be used in some payment and trading scenarios as a stable currency, however, as bitCNY is generated by shorting with BTS as collateral, and the debt position is possible to be force settled at any time, market participants may not have enough incentive to short and as a possible consequence bitCNY is in low supply level. This restricts the growing of relevant economy. What is proposed is to set a compensation from holder to shorter and lower the force settlement volume limit, these will reduce the risk of shorters and encourage them to provide more bitCNY supply. 19 | 20 | # Rationale 21 | 22 | The force settlement offset can be seen as a service fee that holder pay to the settled shorter at the time of force settlement. The offset need to be a proper value that can balance the risk of holders and shorters. A 0 offset is not reasonable enough as in common financial logic the collateral should not be force settled without any compensation if the collateral price does not fall below the margin call price. On the other hand, if the offset is set too high, holders will be discouraged to hold the smartcoin as high offset can make force settlement not feasible. 23 | 24 | As a reference, TCNY has been set a 2% force settlement offset, the consequence is that almost no holder wanted to request force settlement even when the price for the collateral was very low. 25 | 26 | Based on this reference, and the experiences made with current offset in CNY, a 1% offset is proposed with the option of advancing to a time-variable offset updated occasionally. 27 | 28 | Suppose there was no settlement within the last 24 hour, then the maximum volume that can be force settled a 24h-period is 29 | 30 | supply * (1-(1-q)**24)` , with `q = maximum_force_settlement_volume 31 | 32 | (Note: Settlement volume is define in relation to the maintenance interval which is currently 24h) 33 | 34 | Here `p=(1-(1-q)**24)` represent the maximum percentage of the supply that can be force settled in 24 hours, then 35 | 36 | if q=3% p=51.9% 37 | if q=2% p=38.4% 38 | if q=1% p=21.4% 39 | if q=0.5% p=11.3% 40 | if q=0.2% p=4.7% 41 | 42 | `q=0.5%` should be a reasonable choice with at most 11.3% of supply that can be force settled in one day. 43 | 44 | # Specification 45 | 46 | A committee proposal will change the 2 parameters of bitCNY from 47 | 48 | force_settlement_offset_percent = 0 49 | maximum_force_settlement_volume = 2% per maintenance interval 50 | 51 | to 52 | 53 | force_settlement_offset_percent = 1% 54 | maximum_force_settlement_volume = 0.5% per maintenance interval 55 | 56 | The expiration time will be set to **30 days** for relevant users to respond and operate. 57 | This notice gives 58 | 59 | * **shareholders** time to evaluate the proposal and remove support from committee members that do not vote in their favor 60 | * **longs** time to sell or settle their long position prior to the installation of the new settings 61 | * **shorts** time to adjust their trading strategies for bitCNY 62 | 63 | # Discussion 64 | 65 | ### Will bitCNY be "devalued" after this change? 66 | 67 | It is our opinion that *force settlement* is a service. This change is to ask holders to pay a small percentage (1%) fee to shorters when requesting force settlement. If the proposal is accepted by the committee, bitCNY is *devalued* by 1% **if** force settlement was the only way for this smartcoin to quit. However, bitCNY can still be traded in the regular market including markets to other assets. 68 | Hence, we do not see that bitCNY are "devalued". 69 | 70 | ### Should this change be applied to other smartcoin such as bitUSD? 71 | 72 | Based on the same logic, it makes sense to apply the same change to other smartcoins, but to be cautious, it is proposed to first apply the change to bitCNY, after observation and review with long enough time, it can be considered to apply the change to other smartcoins. This, however, will require another written proposal and is not covered by this BSIP! 73 | 74 | ### Does this proposal break a promise? 75 | 76 | Yes, but maybe not! There were promises made that bitassets can be settled at any time at the *fair price* (price feed). With this proposal, we ask for a percentage fee for the settlement service. This can be interpreted as breaking a promise while it could also be interpreted as a change in fee schedule: "Settlements are free for the first few months, after that they are 1%". 77 | 78 | # Summary for Shareholders 79 | 80 | Currently, there is no settlement offset which means that longs can settle their position *at* the price feed. The consequence is that market participants are not selling their bitCNY at the price feed but slightly higher knowing that they could always settle at the feed via settlement. 81 | 82 | By asking for a percentage of the settled volume, the premium is assumed to be reduced and bitCNY will be traded more tightly around parity. Since the settlement offset is paid by the long position to the settled shot position, shorters are compensated for providing bitCNY. Because settlements happen on a 24h notice, we expect shorts to adjust their collateral to *catch* settlement orders and make a profit. 83 | 84 | For the long position, the settlement offset appears as if it was a percentage fee for the serivce of settlement after 24h. 85 | 86 | 87 | # Copyright 88 | 89 | This document is placed in the public domain. 90 | -------------------------------------------------------------------------------- /bsip-0019.md: -------------------------------------------------------------------------------- 1 | 2 | BSIP: #019 3 | Title: Introducing profit-sharing/dividends to Bitshares (MPA only) 4 | Authors: [Customminer](https://steemit.com/@cm-steem/) 5 | Status: Deferred 6 | Type: Protocol 7 | Created: 2017-06-18 8 | Primary Discussion: https://bitsharestalk.org/index.php/topic,23981.0.html 9 | Similar Discussions: https://bitsharestalk.org/index.php/topic,23706.0.html , https://bitsharestalk.org/index.php/topic,21476.msg279498.html#msg279498 , https://bitsharestalk.org/index.php/topic,23707.0.html 10 | Replaces: N/A 11 | Superseded-By: N/A 12 | Worker: No worker proposal yet - propose bounty? 13 | 14 | --- 15 | 16 | # Abstract 17 | 18 | The introduction of 'profit sharing / dividends' for [BTS|MPA] on the Bitshares DEX via the redistribution of fees. 19 | 20 | --- 21 | 22 | # Motivation 23 | 24 | One of the major selling points of BTSX (for myself) back in 2014 was the 5% (really variable x%) on 'anything' marketing. 25 | 26 | The idea that anyone could securely hold MPAs long term in their wallet and receive better 'interest' rates than that FIAT banks were offering was (and remains) a powerful message which had myself (and a lot of other users) sold on Bitshares. 27 | 28 | During the migration from BTSX (BTS 0.9x) to BTS 2.0 we removed 'socialized yield' due to '[yield harvesting](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)'. I believe that its removal without an established replacement income stream for asset holders was a mistake (one that we can amend). 29 | 30 | The last monthly gathered fee estimate was approximately 1 million BTS per month which is approximately $330,000 (not an insignificant sum), of which 80% was distributed to the referral system (20% goes to the reserve pool). 31 | 32 | The Bitshares DEX [recently turned a profit](https://steemit.com/bitshares/@steempower/bitshares-state-of-the-network-13th-june-2017)! 33 | 34 | Peerplays has [already implemented profit sharing in graphene](https://github.com/BunkerChainLabsInc/peerplays-profitshare). 35 | 36 | --- 37 | 38 | # Rational 39 | 40 | * The potential for profiting more by holding your assets on the BTS DEX than within a traditional FIAT bank (without taking on risk) could drive many new users to pick the BTS DEX over centralized banks for storing their savings in the future. 41 | * An increased demand for MPA leads to an increased MPA supply and thus a reduction in the quantity of liquid BTS (since 200-300% BTS are locked up as collateral for each MPA token). 42 | * An increase in MPA supply potentially encourages greater MPA liquidity on the BTS DEX. 43 | * Other cryptocurrency platforms offer profit-sharing/dividends, such as [Peerplays](https://github.com/BunkerChainLabsInc/peerplays-profitshare)/NXT/CounterParty/DigixDAO/LBRY/Waves/Dash. 44 | * By incentivizing Bitshares users to hold their BTS on the DEX instead of on centralized exchanges we minimize the risk of said centralized exchanges having a massive voting weight with which they could disrupt BTS operations by voting maliciously. 45 | * We can reallocate fee redistribution without increasing fees by reducing referral fee allocation. 46 | 47 | --- 48 | 49 | # Specifications 50 | 51 | ## Implementation of Peerplays profit sharing mechanism 52 | The Peerplays developement team developed [profit-sharing code for the Graphene toolkit](https://github.com/BunkerChainLabsInc/peerplays-profitshare) approximately one year ago, they have repeatedley given permission for the BTS DEX to utilise their developed profit-sharing code ([case 1](https://bitsharestalk.org/index.php/topic,23981.75.html), [case 2](https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares#@peerplays/re-cm-steem-bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares-20170620t032010758z)). A large portion of the work required for this BSIP may already be complete. 53 | 54 | ## Fee redistribution variables 55 | The fee redistribution values should be discussed thoroughly and either decided by the committee (smartcoins) or the MPA issuer (non-smartcoin assets such as Algorithm based Assets). 56 | 57 | ### Potential fee redistribution variables: 58 | 59 | * #### Higher level fee redistribution groups 60 | * Reserve pool : % 61 | * [Referral system](http://docs.bitshares.eu//bitshares/user/referral-program.html) : % 62 | * bitAsset (MPA) holders : % 63 | * BTS holders : % 64 | 65 | * #### Account types 66 | * [LTM members](http://docs.bitshares.eu//bitshares/user/account-memberships.html#lifetime-members) : % 67 | * Non-LTM members : % 68 | 69 | * #### Dividend settings 70 | * Dividend schedule (sharedrop timeframe) : Days/Blocks 71 | * Max Coin-Age : Days/Blocks 72 | * Bonus rate for age past max coin-age : % 73 | * MPA dividends permissions : Enable/Disable 74 | * MPA dividend prioritization : Equal split between all MPA (subsidizing less active MPA), or proportional to [trading volume|MPA supply]. 75 | 76 | ## Basis for distribution within sharedrop timeframe 77 | * Dividends is paid on a scheduled basis as opposed to on user demand 78 | * Dividends are paid based on MPA asset holdings 79 | * 'Coin-age' of asset holdings 80 | * Split of network fees between MPA tokens, either on an equal split or proportional basis. 81 | 82 | ## Whitelist/Blacklist options 83 | 84 | * Configured by the Committee or the MPA issuer. 85 | * An optional whitelist could provide increased control over who is eligible to earn dividends on their MPA holdings. 86 | * An optional blacklist could prevent exchanges/services from earning dividends/interest on MPA (incentivizing holding MPA on the BTS DEX over centralized exchanges). 87 | 88 | --- 89 | 90 | # Discussion 91 | 92 | ## Is BSIP19 vulnerable to 'yield-harvesting'? 93 | A quote from the '[Socialized yield is broken](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)' blog post: 94 | 95 | > "Under BitShares the BitAsset holders receive a yield simply by holding BitUSD. This yield was between 1% and 5% APR on average. Unfortunately, yield harvesting can happen at any time by someone shorting to themselves to gain a very low risk return and undermining goal of encouraging people to buy and hold BitUSD. The yield was funded from transaction fees and by interest paid by shorts." 96 | 97 | * Rather than paying profit to shorters on demand, this BSIP proposes scheduled dividends against BitAsset (MPA) holders via the redistribution of network fees. 98 | * If we simply took a snapshot of user asset holdings at the immediate time of dividend issuance then users could create the asset immediately prior to the scheduled dividend after which they could settle the token back to BTS. To prevent this behaviour, we need to take the age of asset holdings into account. 99 | * Thus BSIP19 is not vulnerable to the 'yield-harvesting' issue that was prevalent within 'Socialized Yield'. 100 | 101 | ## Collateralized Bonds 102 | The concept of "[Collateralized Bonds](https://bitshares.org/blog/2015/06/08/lessons-learned-from-bitshares-0.x/#socialized-yield-is-broken)" has yet to materialize within Bitshares 2.0, so in effect we cut asset holders out of fee redistribution (by removing 'socialized yield') without providing a replacement source of income for holding assets on the Bitshares DEX. 103 | 104 | ## Additional topics for discussion 105 | * Should exchanges be exempt from receiving dividends? 106 | * Should LTM users receive a separate bonus dividend? Specifically, BTS dividends for holding BTS 107 | * Can we pay out dividends in MPA, or will we have to distribute BTS? 108 | * Is there a better idea than 'coin-age' for fair dividend distribution? 109 | * What's a fair max coin-age? The sharedrop timeframe? 110 | * Should coin-age greater than the sharedrop timeframe receive a bonus modifier? 111 | * Who can perform this work? 112 | * How much should a worker proposal charge for this task? 113 | 114 | --- 115 | 116 | # Summary for Shareholders 117 | * No worker proposal has been created yet, input from coders regarding the cost is necessary. 118 | * This BSIP does not propose values for these fees, this is up to the discretion of the network & committee. 119 | * The fees distributed towards the referral system will be reduced to make room for profit-sharing. 120 | 121 | --- 122 | 123 | # Copyright 124 | Peerplays created the [profit-sharing functionality](https://github.com/BunkerChainLabsInc/peerplays-profitshare) w/ MIT license: 125 | * > "[The code was created by Bunkerchain Labs Inc. and licensed MIT. So long as MIT parameters are met it can be used in Bitshares.](https://steemit.com/bitshares/@cm-steem/bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares#@peerplays/re-cm-steem-bsip-019-draft-introducing-profit-sharing-dividends-to-bitshares-20170620t032010758z)" - Peerplays (Steemit) 126 | * > "[Implement our profit sharing code thanks to Peerplays development](https://bitsharestalk.org/index.php/topic,23981.75.html)" - BunkerChainLabs (Bitsharestalk) 127 | 128 | # See Also 129 | * [BSIP-19 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-019-updated-draft-introducing-profit-sharing-dividends-to-bitshares-mpa-only) 130 | -------------------------------------------------------------------------------- /bsip-0021.md: -------------------------------------------------------------------------------- 1 | BSIP: #021 2 | Title: Introducing the 'Coin-Age' statistic to Bitshares assets 3 | Authors: [Customminer](https://steemit.com/@cm-steem/) 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2017-07-03 7 | Primary Discussion: https://steemit.com/bitshares/@cm-steem/bsip-020-draft-introducing-profit-sharing-dividends-to-bitshares-uia-only-input-would-be-massively-appreciated 8 | Similar Discussions: N/A 9 | Replaces: N/A 10 | Superseded-By: 11 | Worker: N/A 12 | 13 | # Abstract 14 | 15 | Introducing the ability to query the 'Coin-Age' of assets held by individuals upon the BTS DEX. 16 | 17 | # Motivation 18 | 19 | * There exists no directly queryable 'coin-age' statistic within the Bitshares network. 20 | * Currently, the closest we can get to querying an account's accumulated asset coin-age within the client is query an account's transaction history then calculate the coin-age with an external script. 21 | * There aren't currently any open-source scripts for calculating user asset coin-age. 22 | 23 | # Rational 24 | 25 | * BSIPs 19 and 20 (Introducing profit-sharing/dividends for MPA(19)/UIA(20)) both reference a non-existent 'coin-age' statistic. 26 | * Proposed for proportionally distributing profit/dividends based on the length of time an asset has been held in the user's balance within the dividend time period, preventing abuse of the scheduled dividend. 27 | * We have experienced market fluctuations/instability caused by publicly scheduled snapshots (users buy immediately before, snapshot, sell immediately afterwards); discouraging similar practices through the inclusion of 'coin-age' in the dividend mechanism could help neutralise this issue. 28 | * Regarding consensus, there hasn't been sufficient discussion for users to voice disagreement against coin-age proposals. 29 | * A legit concern is that if there are a significant quantity of asset holders & transactions to process, that evaluating accumulated_coin_age for all users could be computationally expensive. 30 | * A concern regarding coin-age that this BSIP accounts for is if coins are held longer than the user specified time_period, that the coins start representing more than one of themselves (1 being worth 2 if held 2 times longer than the user input time period). 31 | 32 | # Specifications 33 | 34 | * For each chunk of a specific asset transfered to an user in the past, enable the easy querying/calculation of each user's accumulated 'coin-age' statistic. 35 | * Possible route: 36 | * 1. Retrieve list of accounts holding chosen asset 37 | * 2. Given this list, query the account's current asset holdings (for chosen asset), returning the list of transactions that make up holdings. 38 | * 3. Evaluate coin-age from list of tx for each eligible asset holder. 39 | 40 | * Draft coin-age calculation: (very much so example pseudocode, not production code!) 41 | ``` 42 | let reference_asset = USD; //User input variable 43 | let time_period = 30 days; //User input variable 44 | let accumulated_coin_age = 0; 45 | let reference_time = current_time; //User input variable 46 | 47 | if (whitelisted_accounts) { 48 | let eligible_asset_holders = whitelisted_accounts //whitelist input by user 49 | } else if (blacklisted_accounts) { 50 | let eligible_asset_holders = asset_holder_list - blacklisted_account_list //blacklist input by user 51 | } else { 52 | let eligible_asset_holders = asset_holder_list //include all asset holders. 53 | } 54 | 55 | for each asset_holder in eligible_asset_holders { 56 | for each tx in asset_holdings { 57 | let tx_balance = current_tx_balance //Get the quantity of coins present in this transaction 58 | let time_diff = current_date - tx_inbound_date //Get the age of the transaction 59 | 60 | if (time_diff > time_period) { 61 | accumulated_coin_age += tx_balance //Prevent coins being worth more if held longer than time_period. Increase time_period to provide this functionality. 62 | } else { 63 | accumulated_coin_age += ((time_diff/time_period)*tx_balance) 64 | } 65 | } 66 | //Store current asset_holder & accumulated_coin_age in [hashmap|storage] for later referencing 67 | } 68 | ``` 69 | * Coin-Age based individual-user dividend calculation: 70 | ``` 71 | if (whitelisted_accounts) { 72 | let total_eligible_token_supply = assets_held_by_whitelisted_accounts 73 | } else if (blacklisted_accounts) { 74 | let total_eligible_token_supply = total_supply - assets_held_by_blacklisted_accounts 75 | } else { 76 | let total_eligible_token_supply = total_supply 77 | } 78 | 79 | let total_distributable_tokens = 1000 OPEN.GRC; //quantity & token type set by user 80 | 81 | for each asset_holder in coin_age_hashmap { 82 | dividend_allocation = (accumulated_coin_age/total_eligible_token_supply)*total_distributable_tokens 83 | } 84 | ``` 85 | 86 | # Discussion 87 | 88 | ## How does coin-age prevent abuse of BSIPs 19 & 20? 89 | 90 | * If we were to perform a scheduled dividend based on a static snapshot of immediate account holdings, users could purchase the asset immediately prior to the scheduled dividend, receive the dividend then sell immediately afterwards, potentially causing market instability/fluctuations around the scheduled dividend. 91 | * We have experienced this form of market instability in the past for protoshares (around past sharedrops) and for BTS (for peerplays). 92 | (buy immediately beforehand, sell immediately afterwards, causing market instability around the scheduled dividend). 93 | 94 | ## Potential alternatives to 'coin-age' for preventing abuse of a dividend system 95 | 96 | * Random snapshot date within sharedrop time period (similar to peerplay's secret snapshot date within possible snapshot range). 97 | * Downsides: Assets held outwith the moment of snapshot within the snapshot time period are not eligible for receiving dividends. 98 | * Increasing market fees on the days surrounding the scheduled sharedrop? If an UIA has an additionally enabled fee market, a premium fee could be enabled potentially encouraging users to buy the assets earlier in the month & providing longer term asset holders additional profit? Would ony be possible for UIA, not MPA. 99 | * Disabling of market trading in the days surrounding the dividend payment? This would be incresibly heavy handed & potentially scare asset holders, especially if the asset price fluctuaed on external exchanges. 100 | * Entirely disregard any concerns of dividend system abuse? Openledger currently performs regular sharedrops onto Obits holders without taking coin-age into account! 101 | 102 | # Summary for Shareholders 103 | 104 | * No impact on shareholders, this would simply enable an additional queryable statistic within the Bitshares network for additional functionality proposed in BSIPs 19 and 20 to take advantage of. 105 | * No worker proposal nor bounty proposed yet, simply brainstorming documentation within the community! 106 | * Will be discussed/mentioned in a future BeyondBitcoin hangout. 107 | 108 | # Copyright 109 | 110 | This document is placed in the public domain. 111 | 112 | # See Also 113 | * [List account balances - Graphene documentation](http://docs.bitshares.org/api/database.html#id8) 114 | * [BSIP 21 Steemit thread](https://steemit.com/bitshares/@cm-steem/bsip-0021-draft-introducing-the-coin-age-statistic-to-bitshares-assets-input-would-be-massively-appreciated) -------------------------------------------------------------------------------- /bsip-0022/changing-decay-parameters.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0022/changing-decay-parameters.png -------------------------------------------------------------------------------- /bsip-0022/general-vote-decay.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0022/general-vote-decay.png -------------------------------------------------------------------------------- /bsip-0022/historical-bts-voting-participation-rate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0022/historical-bts-voting-participation-rate.png -------------------------------------------------------------------------------- /bsip-0022/historical-bts-voting-stake-with-hypothetical-decay.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0022/historical-bts-voting-stake-with-hypothetical-decay.jpg -------------------------------------------------------------------------------- /bsip-0024.md: -------------------------------------------------------------------------------- 1 | BSIP: BSIP-0024 2 | Title: Locking Bitshares away as 'Bitshares Influence' for voting privileges on the BTS DEX 3 | Authors: [Customminer](https://steemit.com/@cm-steem/), Taconator, jcalfee. 4 | Status: Draft 5 | Type: Protocol 6 | Created: 29/08/2017 7 | Discussion: https://github.com/bitshares/bsips/issues/28#issuecomment-324512215 https://steemit.com/bitshares/@officialfuzzy/bitshares-hangout-35-2017-08-25-opensource-agenda-whaleshare-beyondbit-payouts-powered-by-sp#@taconator/re-officialfuzzy-bitshares-hangout-35-2017-08-25-opensource-agenda-whaleshare-beyondbit-payouts-powered-by-sp-20170825t120002506z https://steemit.com/bitshares/@cm-steem/draft-bsip-0024-locking-bitshares-away-as-bitshares-influence-for-voting-privileges-on-the-bts-dex 8 | Replaces: N/A 9 | Superseded-By: N/A 10 | Worker: N/A 11 | 12 | # Abstract 13 | 14 | Introduce functionality to lock Bitshares (BTS) away as 'Bitshares Influence' which will be required to vote upon Witness/Committee members and Worker-Proposals. 15 | 16 | # Motivation 17 | 18 | * Services and or exchanges currently have the ability to vote upon witnesses/committee members and for worker proposals, potentially to the detriment of the network and with disregard to their userbase. 19 | * Blacklisting/Whitelisting of accounts from the voting mechanism (to prevent abusing customer's funds) is not a desirable outcome for a decentralized network & wouldn't be effective. 20 | 21 | # Rational 22 | 23 | * If you were required to lock away your BTS in an 'Bitshares Influence' balance which you couldn't immediately withdraw said BTS from (say withdraw over several weeks), then exchanges/services would potentially be less likely to vote with their userbase's funds as their userbase would know (publicly auditable) that they have insufficient funds to satisfy customer withdrawls (serving withdrawls with other user's deposits instead of transfering cold storage funds to hot wallets). 24 | * Reduced liquid Bitshares on centralized exchanges. 25 | * Valuable target for UIA sharedrop & dividend payments. 26 | * "There is significant value to having long-term commitment because it enables communities to make long-term plans. Long term commitment of stakeholders also causes them to vote for long-term growth rather than short-term pumps." - [Steem whitepaper](https://steem.io/SteemWhitePaper.pdf#h.3si6qbxpv4do) 27 | 28 | # Specifications 29 | 30 | * Create new balance type 'Bitshares Influence' (Or Bitshares Power, whatever sounds best - BTSI vs BTSP). 31 | * Modify voting system to use Bitshares Influence balance instead of Bitshares, potentially with a slow switch over period to prevent sudden change in voting outcome due to votes being reset-to-zero. 32 | * Provide the committee the ability to modify the rate at which Influence can be converted back to Bitshares (weeks, months, etc). 33 | * Potentially still involve Bitshares (non locked away influence) tokens in the voting mechanism, but with a reduced voting weight (say 10% for an initial guesstimate). 34 | * Potentially allow for the use of Bitshares influence as backing collateral for MPA, so as to not deplete the MPA markets of liquidity. When they settle their debt, the BTS goes back into the influence balance whilst the profit is liquid. 35 | 36 | # Discussion 37 | 38 | ## How should influence vote weight be distributed? 39 | 40 | * A: (user_influence/total_influence)*total_coin_supply 41 | * B: user_influence 42 | 43 | 'A' would likely provide more than 1 BTS of vote weight per 1 BTSI, as not all coins would be locked away as influence. 44 | 'B' is simply your current bitshares influence, nothing else taken into account. 45 | 46 | Would there even be a difference in voting behaviour betwen the two? Perhaps it might make the influence holders feel like their BTS are more valuable than non-influential BTS? 47 | 48 | ## Potential issues 49 | 50 | * Exchanges/Services with large & old non-liquid cold storage accounts may be perfectly fine with locking away funds in a 'Bitshares Influence' balance, as it would potentially add further security to cold wallet funds (An attacker couldn't immediately transfer funds) & because their userbase may not be paying attention to nor regularly auditing the exchange/service's hot/cold bitshares accounts. 51 | * If this reduces voting participation & exchanges lock away funds in this manner, then the exchange/service may end up with more voting weight than they originally did. 52 | * A lack of liquid Bitshares could cause: 53 | * Wild swings in centralized exchange BTS price - potentially bad for MPA reference prices, perhaps triggering global settlement events (BSIP-0018 should offset this concern). 54 | * A lack of MPA liquidity, if users aren't using their BTS as backing collateral to short MPA into existence. 55 | * In switch over from BTS to BTSI for voting power, if we do not snapshot past votes or slowly taper from one voting system to the other, we could encounter a period of unstable voting. If everything was reset to zero, then malicious actors could attempt to be voted into power. 56 | 57 | # Summary for Shareholders 58 | 59 | * Significant proposed changes to voting power - you will need to lock away funds in order to vote after the implementation of this BSIP. Unlocking funds could take weeks. 60 | * Will require a hard fork for implementation which could potentially cause temporary network disruption. 61 | * No worker proposal yet, requires developer input. 62 | 63 | # Copyright 64 | 65 | This document is placed in the public domain. 66 | 67 | # See Also 68 | 69 | N/A 70 | -------------------------------------------------------------------------------- /bsip-0025.md: -------------------------------------------------------------------------------- 1 | BSIP: 00025 2 | Title: Transaction Flat-Rates with Weighted Rate-Limitation 3 | Authors: Fabian Schuh 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2017-10-16 7 | Worker: T.B.D. 8 | 9 | # Abstract 10 | 11 | Blockchain technology currently depends upon transaction fees to prevent 12 | spam. These fees suffer all of the known problems with 13 | micro-transactions and prevent blockchains from being used for low-value 14 | transactions, massive trading and high-rate market making. Truly 15 | decentralized applications must offer users the *appearance* of free 16 | transactions if they wish to compete with their centralized 17 | alternatives. 18 | 19 | This document proposes a protocol upgrade to BitShares to introduce 20 | rate-limitations for *fee-free* transactions. Since the BitShares 21 | blockchain is entitled to be a profitable decentralized autonomous 22 | company (DAC), making use of *fee-free* transactions comes at a 23 | *monthly* fixed cost as well as the option to lock shares away in a 24 | vesting balance in order to increase the standard rate at which users 25 | may interact with the blockchain. 26 | 27 | # Motivation 28 | 29 | Blockchains are decentralized networks where all transactions are 30 | broadcast to all peers. Every so often a block is produced that includes 31 | some or all of the pending transactions. All blockchains must find a 32 | solution to prevent malicious users from consuming all of the available 33 | network capacity with worthless transactions. These worthless 34 | transactions can prevent other valuable transactions from being 35 | processed and ultimately destroy the network. 36 | 37 | The solution adopted by most blockchains thus far is to charge a minimum 38 | transaction fee. A fee worth just a few cents is enough to make 39 | attacking the network expensive and unprofitable. While this approach 40 | solves the spam problem, it introduces new problems. 41 | 42 | Market making as well as micro-transactions are a highly competitive 43 | market. Being *decentralized* and *trust-less* alone, does not make the 44 | BitShares blockchain a good competitor when compared to centralized 45 | services. 46 | 47 | Despite blockchain transactions being cheaper *technically*, the fee 48 | that is attached to each and every transaction on BitShares results in 49 | some crucial businesses to be unviable, such as **market making** at 50 | scale, where dozens of orders are created (and canceled) continuously, 51 | in order to provide liquidity to the markets. 52 | 53 | # Rational 54 | 55 | In this proposal, we extend the BitShares fee model to allow 56 | transactions made by accounts to go through without paying a fee. We 57 | require accounts to be lifetime members to harness a **transaction 58 | flat-rate** with certain limits that can be raised by additionally 59 | providing BTS (units of the core asset) in a vesting balance that is 60 | locked away for a certain amount of time, only do be made liquid in 61 | weekly chunks over the whole period. 62 | 63 | ## Full Reserve vs Fractional Reserve 64 | 65 | Let's view a blockchain like an Internet Service Provider (ISP) co-op 66 | which owns all of the cables in the town and can process a maximum 67 | amount of data transmission on those cables at any time. This is called 68 | *the capacity* of the transmission lines. People living in the town can 69 | buy shares in the ISP and obtain the right to utilize a portion of the 70 | available capacity. 71 | 72 | The ISP has two choices and can either run a **full reserve** or 73 | **fractional reserve** system. 74 | 75 | * Under a full reserve system each user is only allowed a fraction of 76 | the capacity proportional to her shares. Because not everyone uses 77 | the Internet at the same time, the town's network would be significantly 78 | underutilized. 79 | * Under a fractional reserve system the individual users could utilize 80 | more date rate than they are entitled to at any given point in time so 81 | long as not everyone uses the Internet at the same time. 82 | 83 | The problem with operating a fractional reserve is that congestion 84 | occurs anytime too many people wish to use the network at the same time. 85 | The ISP needs a way to prioritize transmissions during congested 86 | periods. In the most extreme case, a fully congested network must revert 87 | to a full reserve system. 88 | 89 | The challenge is setting the proper fractional reserve ratio or 90 | implement a **dynamic fractional reserve ratio**. Under this model the 91 | blockchain will 92 | automatically adjust the reserve ratio for the network during times of 93 | congestion. The blockchain will set a target utilization that leaves 94 | enough headroom for short term surges in demand. Any time the surges 95 | are sustained the blockchain reduces the maximum rate-per-share. 96 | When a surge is over and there is surplus capacity the blockchain can 97 | slowly increase the rate-per-share. 98 | 99 | If the time window for this control cycle is stretched too far then the 100 | reserve ratio will not adjust fast enough to respond to short-term 101 | surges, if the window is too short then clustering usage will have too 102 | big of an impact on normal users. 103 | 104 | In our estimate it should be sufficient to measure the average weekly 105 | transaction rate usage of users. This parameter will be changeable by 106 | the BitShares committee. The advantage with this approach is, that the 107 | BitShares committee can define whether they prefer a dynamic fractional 108 | reserve, where occasional uses may transact more often within a very 109 | short period of time, or a simple and static method, where professional 110 | users get an easy picture of how many transactions they may produce in a 111 | certain amount of time. 112 | 113 | ## Flat-Rate Model 114 | 115 | In recent years, ISP providers have seen a shift in their own economics 116 | leaving the *pay-per-use* (e.g. per minute) service domain where users 117 | paid for a duration they occupied a land-line to go for a 118 | *pay-per-serice* flat-rate model where users paid a fixed fee to enable 119 | a specific service to be used for free within certain conditions (e.g. 120 | data volume). With the improvements in communications technology, land 121 | lines got replaced by fiber which can carry significantly more load. 122 | Thus the flat-rate model makes sense from business perspective. 123 | 124 | The same holds true for blockchain technologies. The Graphene framework 125 | is capable of incomparable transaction loads and thus, the individual 126 | transaction may not be tagged with a fee for the profit alone, but 127 | merely to prevent spam. A full reserve system gives value to a 128 | transaction processing capabilities of the blockchain which everyone can 129 | own a share of to prevent spam. 130 | 131 | ## Flat-Rate with Weighted Rate-Limitation 132 | 133 | That said, we here propose a combination of the flat-rate model with a 134 | stake-weighted limitation of transaction rates. 135 | 136 | * **Flat-Rate**: A new feature is added to the blockchain that enables 137 | the flat-rate model with a basic transaction rate that can be defined 138 | by the BitShares committee (e.g. 10 transactions per day). This 139 | operation costs a fee and lasts for a committee-parameterized amount 140 | of time (e.g. 30 days). These rates are the same for every single user 141 | that has bought the flat-rate subscription. 142 | 143 | * **Stake-Weighting**: Since some users may need more than the basic 144 | amount of transactions per day, power users can increase the 145 | implicitly assumed weight of 1x to a higher value by providing BTS 146 | core tokens in a vesting balance locks them away for as long as the 147 | subscription lasts. 148 | 149 | This ultimately gives the option to 150 | 151 | * pay a fee for every transaction (current system) 152 | * pay for a flat-rate to transaction for fee within certain conditions 153 | * powerup your account with core tokens to increase fee transaction 154 | rate 155 | 156 | # Specifications 157 | 158 | * Do not refund order creation fee! 159 | * Replace Annual Fee operation? 160 | 161 | # Discussion 162 | 163 | Todo 164 | 165 | # Summary for Shareholders 166 | 167 | Todo 168 | 169 | # Copyright 170 | 171 | This document is placed in the public domain. 172 | 173 | # See Also 174 | 175 | 1. [Steem Whitepaper](https://steem.io/SteemWhitePaper.pdf) 176 | -------------------------------------------------------------------------------- /bsip-0026.md: -------------------------------------------------------------------------------- 1 | BSIP: 0026 2 | Title: Refund Order Creation Fee in Originally Paid Asset on Cancel 3 | Authors: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2017-10-16 7 | Discussion: https://bitsharestalk.org/index.php/topic,25153.0.html 8 | Replaces: 0002 9 | Worker: 1.14.69 10 | 11 | # Abstract 12 | 13 | When a user placing an new order, fee can be paid with another asset but not only BTS. Currently, when the order is cancelled and if not partially filled already, an amount of BTS will be refunded to the user. This BSIP proposes refunding in the originally paid assets but not always BTS. 14 | 15 | # Motivation 16 | 17 | Make the asset system easier to use and less vulnerable. 18 | 19 | # Rational 20 | 21 | With the asset fee pool feature, asset holders don't need to hold BTS to pay transaction fees. However, after the "Refund Create Order Fees on Cancel" feature introduced in [Graphene issue #445](https://github.com/cryptonomex/graphene/issues/445) as well as [BSIP #2](https://github.com/bitshares/bsips/blob/master/bsip-0002.md), due to the (inappropriate) design / implementation, fee pools often get drained by 3rd-party bots unexpectedly, which renders the fee pool feature hard to use / less useful. This BSIP proposes a protocol change to prevent fee pool draining from happening, while still keeping a similar "Refund Create Order Fees on Cancel" feature in the system. It brings following benefits: 22 | * If a user created an order with fees paid in one asset, it's more acceptable for her to be refunded in same asset when the order is cancelled. 23 | * If the same asset paid is refunded, exploiters/bots will be unable to drain the fee pools. 24 | 25 | # Specifications 26 | 27 | ## Current Design and Implementation 28 | 29 | Always refund fee in the form of CORE asset (BTS), even if fee was paid with another asset. 30 | 31 | * When a new order is created, if fees are paid in an asset other than BTS, that fees will be added to the asset's `accumulated_fees` field right away, in the same time some BTS will be deducted from the fee pool according to the asset's CER then be put into the `deferred_fee` field of the new created `limit_order_object`. 32 | * When the order got filled or partially filled, the BTS in `deferred_fee` field will be directed to referral program. 33 | * If the order be cancelled manually before partially filled, the BTS in `deferred_fee` field will be sent to the owner's balance. 34 | * If the order be cancelled automatically due to expiration or too small to fill, a cancellation fee will be deducted from `deferred_fee` but capped by the remaining amount, then the cancellation fee (if any) will be redirected to referral program, the yet remaining amount (if any) in `deferred_fee` will be sent to the order owner's balance. 35 | 36 | ## Proposed Changes 37 | 38 | Always refund fee in the form of paid asset. 39 | 40 | * When a new order is created, if fees are paid in an asset other than BTS, store the fees to the new order's `deferred_paid_fee` field (a new field) but not add it to the asset's `accumulated_fees` field right away, in the same time deduct some BTS from the fee pool according to the asset's CER and put it into the `deferred_fee` field of the new created `limit_order_object`. Say, the order owes the system some fees in BTS and owe the asset issuer some fees in that asset. 41 | * When the order got filled or partially filled, redirect the BTS in `deferred_fee` field to referral program, at the same time send the assets in `deferred_paid_fee` field to the asset's `accumulated_fees` field. 42 | * If the order be cancelled manually before partially filled, send the BTS in `deferred_fee` field to the asset's fee pool, and send the assets in `deferred_paid_fee` field to the owner's balance. 43 | * If the order be cancelled automatically due to expiration or too small to fill, deduct a cancellation fee from `deferred_fee` but capped by the remaining amount, then redirect the cancellation fee (if any) to referral program; if the cancellation fee is positive, deduct an amount equals to `round_up(cancellation_fee_in_bts * deferred_paid_fee / deferred_fee_before_deduct)` of assets from `deferred_paid_fee` but capped by the remaining amount then send it to the asset's `accumulated_fees` field; then send the yet remaining amount (if any) in `deferred_fee` to the fee pool, send the yet remaining amount (if any) in `deferred_paid_fee` to the order owner's balance. 44 | 45 | 46 | # Discussion 47 | 48 | When creating an asset, with current design, the issuer is forced to put half of creation fee into the new asset's fee pool. But not all people like this feature. It's better if the fee pool filling is optional when creating a new asset. 49 | 50 | Asset issuers may want a dedicated operation to get out some BTS from the fee pool, for example when accidentally filled too much BTS into the pool. This is discussed in [bitshares-core issue #188](https://github.com/bitshares/bitshares-core/issues/188). If this BSIP is implemented, asset issuers will be no longer able to get out the BTS from the fee pool by cancelling an order. 51 | 52 | # Summary for Shareholders 53 | 54 | [to be added] 55 | 56 | # Copyright 57 | 58 | This document is placed in the public domain. 59 | 60 | # See Also 61 | 62 | * https://github.com/cryptonomex/graphene/issues/445 63 | * https://github.com/bitshares/bitshares-core/issues/188 64 | * https://bitsharestalk.org/index.php/topic,25153.0.html 65 | -------------------------------------------------------------------------------- /bsip-0027.md: -------------------------------------------------------------------------------- 1 | BSIP: 0027 2 | Title: Asset Issuer Reclaim Fee Pool Funds 3 | Authors: Abit More 4 | Fabian Schuh 5 | Status: Installed 6 | Type: Protocol 7 | Created: 2017-11-02 8 | Discussion: https://github.com/bitshares/bitshares-core/issues/188 9 | Worker: 1.14.70 10 | 11 | # Abstract 12 | 13 | Asset issuers need a way to get out some CORE assets (BTS) from their assets' fee pool, for example when accidentally filled too much BTS into the pool. As of writing, this can be done by crafting a special limit order then cancel it, the process is a bit complicated. In addition, this approach will no longer work if [BSIP #26 (Refund Order Creation Fee in Originally Paid Asset on Cancel)](https://github.com/bitshares/bsips/blob/master/bsip-0026.md) is implemented. This BSIP proposes a protocol change to meet the demand. 14 | 15 | # Motivation 16 | 17 | Make the asset system easier to use. 18 | 19 | # Rational 20 | 21 | Asset issuer should have full and easy control over the funds in the fee pool. 22 | 23 | # Specifications 24 | 25 | ## Current Design and Implementation 26 | 27 | Asset issuers can fill the fee pool with the `asset_fund_fee_pool_operation` operation, which has a structure as follows: 28 | ``` 29 | struct asset_fund_fee_pool_operation : public base_operation 30 | { 31 | asset fee; ///< core asset 32 | account_id_type from_account; 33 | asset_id_type asset_id; 34 | share_type amount; ///< core asset 35 | extensions_type extensions; 36 | }; 37 | ``` 38 | 39 | The `amount` in the structure can only be positive, which means the `from_account` can only add some CORE asset (BTS) into an asset's fee pool. 40 | 41 | ## Proposed Changes 42 | 43 | We propose to add a new operation `asset_claim_pool_operation` that allows to claim CORE asset (BTS) from the fee pool. 44 | 45 | ``` 46 | struct asset_claim_pool_operation : public base_operation 47 | { 48 | asset fee; 49 | account_id_type issuer; 50 | asset_id_type asset_id; /// fee.asset_id must != asset_id 51 | asset amount_to_claim; /// core asset 52 | extensions_type extensions; 53 | }; 54 | ``` 55 | 56 | We've decided to add a new operation in order to no modify existing behavior. 57 | 58 | # Discussion 59 | 60 | The operation fee for `asset_claim_pool_operation ` should be no less than `transfer_operation`. 61 | 62 | # Summary for Shareholders 63 | 64 | We here propose the addition of a new operation that allows to claim fees from the fee pool. Since the fee pools are pre-filled with an initial amount from the asset creation fee, this feature is useful for those that do not desire to use the fee pool. 65 | 66 | # Copyright 67 | 68 | This document is placed in the public domain. 69 | 70 | # See Also 71 | 72 | * https://github.com/bitshares/bitshares-core/issues/188 73 | * [BSIP #2](https://github.com/bitshares/bsips/blob/master/bsip-0002.md) 74 | * [BSIP #26](https://github.com/bitshares/bsips/blob/master/bsip-0026.md) 75 | -------------------------------------------------------------------------------- /bsip-0028.md: -------------------------------------------------------------------------------- 1 | BSIP: 0028 2 | Title: Worker Proposal Improvements 3 | Authors: Bill Butler 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2017-11-11 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/473 8 | https://github.com/bitshares/bitshares-core/issues/451 9 | Worker: TBD 10 | 11 | # Abstract 12 | 13 | Worker Proposals can be posted without a reference to a description of the proposal. It should be possible to update the reference regardless of the state of the worker proposal. There are also cases where proposed workers that fail to get voted in or get superceded by another worker continue to be visible. This isn't a huge problem at the moment, but it is an important housekeeping operation as we move forward. 14 | 15 | # Motivation 16 | 17 | Having clearly defined eligible proposed and active WP's is critical to proper governance. 18 | 19 | # Rational 20 | 21 | Either Committee or WP Issuer should have the abiity to retire a WP. I could make the argument that the WP Issuer should be able to retire their WP at any time whether it's active or not. 22 | 23 | # Specifications 24 | 25 | ## Current Design and Implementation 26 | 27 | Worker Proposals cannot be updated at all 28 | 29 | ## Proposed Changes 30 | 31 | ### Descriptive 32 | 33 | * Allow description of the WP to updated. 34 | * Allow WP Issuer ability to retire WP 35 | * Possibly allow Committee to retire inactive WP 36 | 37 | ### Technical 38 | 39 | * Add bool field `removed` to worker object. 40 | * Add check to `db_maint.cpp` to skip workers in removed state. 41 | * Don't allow votes to workers in removed state(`account_evaluator.cpp`). 42 | * Create operation `worker_update`. Op will allow to change only the `name`, `url` and the `removed` object fields from the worker (track the change in operation). Can follow `committee_member_update` or similars. 43 | * Implement new operation as a command to `cli_wallet` available for the worker issuer. 44 | * Allow `committee` to use `worker_update` against any worker proposal. Need more discussion on how it can be done. 45 | 46 | Requires hardfork. 47 | 48 | # Discussion 49 | ``` 50 | https://github.com/bitshares/bitshares-core/issues/473 51 | https://github.com/bitshares/bitshares-core/issues/451 52 | ``` 53 | # Summary for Shareholders 54 | 55 | [to be added] 56 | 57 | # Copyright 58 | 59 | This document is placed in the public domain. 60 | -------------------------------------------------------------------------------- /bsip-0029.md: -------------------------------------------------------------------------------- 1 | BSIP: 0029 2 | Title: Asset issuer change to require owner authority 3 | Authors: Fabian Schuh 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-01-28 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/199 8 | Worker: 1.14.81 9 | 10 | # Abstract 11 | 12 | With the current design, the issuer of an asset can be changed with the 13 | *active authority* alone. However, this authority is also required for 14 | issuing new units of an asset/token. If this process wants to be 15 | automated, an active key needs to be stored on an internet-connected 16 | device. If compromised, an attacker can easily move the asset under his 17 | control with no way to back. 18 | 19 | This proposal comes with two changes to the protocol: 20 | 21 | 1. The current behavior of changing an assets' parameters will no longer 22 | allow to change the issuer. 23 | 2. A new operation is introduced that allows to change the issuer of an 24 | asset but requires the owner authority of the issuer to sign that 25 | transaction. 26 | 27 | # Motivation 28 | 29 | Improve asset security. 30 | 31 | # Rational 32 | 33 | Assets should not be at risk while automating issuing of new units. 34 | 35 | # Specifications 36 | 37 | ## Current Design and Implementation 38 | 39 | Currently, any asset can be updated with `asset_update_operation`. This 40 | operation contains an optional `new_issuer` that changes the issuer of 41 | the asset. 42 | 43 | ## Proposed Changes 44 | 45 | # `asset_update_operation` 46 | 47 | The existing `asset_update_operation` will be modified in such that it 48 | no longer allows the user of `new_issuer` after a hard fork. 49 | 50 | # `asset_update_issuer_operation` 51 | 52 | A new operation is added with the following construction 53 | 54 | ``` 55 | 56 | struct asset_update_issuer_operation : public base_operation 57 | { 58 | struct fee_parameters_type {uint64_t fee = 20 * GRAPHENE_BLOCKCHAIN_PRECISION; }; 59 | 60 | asset fee; 61 | account_id_type issuer; 62 | asset_id_type asset_to_update; 63 | account_id_type new_issuer; 64 | extensions_type extensions; 65 | 66 | account_id_type fee_payer()const { return issuer; } 67 | void validate()const; 68 | 69 | void get_required_owner_authorities( flat_set& a )const 70 | { a.insert( issuer ); } 71 | 72 | void get_required_active_authorities( flat_set& a )const 73 | { } 74 | 75 | }; 76 | ``` 77 | 78 | This new operation merely allows to change the issuer of an asset and 79 | requires the owner authority (of the issuer account) to sign the 80 | transaction. 81 | 82 | # Summary for Shareholders 83 | 84 | We here propose the addition of a new operation that improves security 85 | of assets with respect to updating the issuer. This closes a long 86 | existing problem that makes running automated issuing of units a 87 | security issue since an attacker that obtains the keys can obtain full 88 | control of an asset indefinitely. This proposal changes this behavior 89 | and requires the owner to sign such change of issuer. 90 | 91 | # Copyright 92 | 93 | This document is placed in the public domain. 94 | 95 | # Sponsoring 96 | 97 | This worker proposal is proudly presented and sponsored by [Blockchain Projects BV](http://blockchainprojectsbv.com). 98 | -------------------------------------------------------------------------------- /bsip-0030.md: -------------------------------------------------------------------------------- 1 | BSIP: 0030 2 | Title: Always Allow Increasing Collateral Ratio If Debt Not Increased 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-16 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/583, 8 | https://github.com/bitshares/bitshares-core/issues/672 9 | Replaces: - 10 | Worker: 1.14.91 11 | 12 | # Abstract 13 | 14 | Currently, when a short position's collateral ratio is below MCR (a parameter 15 | in price feed: `maintenance_collateral_ratio`) but is not completely filled 16 | immediately due to a lack of enough volume on the opposite side of the market, 17 | it will hang in the market and be waiting for being margin called. 18 | 19 | The owner then can adjust the order's collateral ratio **only if** 20 | * to close the position, or 21 | * the new collateral ratio is above MCR, or 22 | * the call order get completely filled (margin called) immediately. 23 | 24 | While this prevents shorters from maliciously reducing collateral ratio (to 25 | increase possibility of black swan event), it also prevents shorters from 26 | slightly increasing collateral ratio (to decrease possibility of black swan 27 | event). 28 | 29 | This BSIP proposes a mechanism to improve this situation. 30 | 31 | # Motivation 32 | 33 | Make the exchange system more user-friendly. 34 | 35 | # Rationale 36 | 37 | The ecosystem would get benefit if shorters are allowed to reduce risks to 38 | themselves while reducing risks to the system at same time. 39 | 40 | Current rules are a bit too strict, which can be loosed to: 41 | 42 | A shorter can adjust the position's collateral ratio **only if** 43 | * to close the position, or 44 | * the new collateral ratio is above MCR, or 45 | * the call order get completely filled (margin called) immediately, or 46 | * **the new ratio is higher than old ratio and debt is not increased** 47 | 48 | # Specifications 49 | 50 | In `do_apply()` function of `call_order_update_evaluator` class, if 51 | finally found the call order still in margin call territory, 52 | * don't throw an exception if `call_obj->collateralization()` is reduced, and 53 | * require `delta_debt` of `call_order_update_operation` to be non-positive. 54 | 55 | # Discussion 56 | 57 | [to be added if any] 58 | 59 | # Summary for Shareholders 60 | 61 | [to be added if any] 62 | 63 | # Copyright 64 | 65 | This document is placed in the public domain. 66 | 67 | # See Also 68 | 69 | * https://github.com/bitshares/bitshares-core/issues/583 70 | * https://github.com/bitshares/bitshares-core/issues/672 71 | * https://bitsharestalk.org/index.php?topic=25926.0 72 | -------------------------------------------------------------------------------- /bsip-0031.md: -------------------------------------------------------------------------------- 1 | BSIP: 0031 2 | Title: Update Short Position's Margin Call Price After Partially Called Or Settled 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-16 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/343, 8 | https://github.com/bitshares/bitshares-core/issues/649 9 | Replaces: - 10 | Worker: 1.14.92 11 | 12 | # Abstract 13 | 14 | Currently, when a short position get partially called or settled, the call 15 | price won't change, that said, even if its actual collateral ratio is higher 16 | than others, higher than minimum required, it will still be selling collateral 17 | at a low price, taking precedence over other short positions. 18 | 19 | This behavior is causing several issues: 20 | * it's somehow unfair, thus brought bad experience to shorters, and 21 | * it prevents black swan event from being triggered in time when needed, 22 | because the collateral ratio of the 2nd even overall short positions may 23 | be too low but not being checked, thus risks the pegging system. 24 | 25 | This BSIP proposes a mechanism to improve this situation. 26 | 27 | # Motivation 28 | 29 | Make the exchange system more user-friendly. 30 | 31 | # Rationale 32 | 33 | To attract more users, the system should be fair, should be well balanced. 34 | 35 | It's common sense that short positions with least collateral ratio should 36 | get margin called first. This can be achieved if always update the margin 37 | call price after every fill. 38 | 39 | # Specifications 40 | 41 | In `fill_order( const call_order_object& ...)` function of `database` class, 42 | update `call_price` field of `call_order_object` after debt or collateral 43 | changed to a non-zero value. 44 | 45 | In addtion, after `call_price` get updated, the iterators initialized with 46 | `by_price` index may be invalidated, so need to review / revise involved code, 47 | E.G. `check_call_orders(...)` function of `database` class. 48 | 49 | # Discussion 50 | 51 | [to be added if any] 52 | 53 | # Summary for Shareholders 54 | 55 | [to be added if any] 56 | 57 | # Copyright 58 | 59 | This document is placed in the public domain. 60 | 61 | # See Also 62 | 63 | * https://github.com/bitshares/bitshares-core/issues/343 64 | * https://github.com/bitshares/bitshares-core/issues/649 65 | * https://bitsharestalk.org/index.php?topic=25926.0 66 | -------------------------------------------------------------------------------- /bsip-0032.md: -------------------------------------------------------------------------------- 1 | BSIP: 0032 2 | Title: Always Match Orders At Maker Price 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-16 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/338 8 | Replaces: - 9 | Worker: 1.14.93 10 | 11 | # Abstract 12 | 13 | Currently, under most circumstances, when matching two orders, the maker price 14 | will be used to calculate how much each order will pay and receive. 15 | However, when matching a taker limit order with a maker margin call order, 16 | the taker price is being used. 17 | 18 | This BSIP proposes a principle: always match orders at maker price. 19 | 20 | # Motivation 21 | 22 | Generally, the order that is placed earlier (the maker) sets a price, 23 | another order that is placed later (the taker) accepts the price, thus a match, 24 | two orders pay to each other at that price. 25 | 26 | Take the pure limit order matching mechanism in BitShares as an example: 27 | If one person (A) placed a limit 28 | order to sell 100 BTS at 0.1 USD per BTS, another person (B) then placed a new 29 | limit order to buy 100 BTS at 0.105 USD per BTS, the two orders will match at 30 | 0.1 USD per BTS, so A will pay 100 BTS and get 10 USD, B will pay 10 USD and 31 | get 100 BTS. 32 | 33 | However, in BitShares, when matching a taker limit order with a maker margin 34 | call order, the taker price is being used. 35 | For example, if trader A's margin call order is 36 | selling 100 BTS at no less than 0.1 USD per BTS, then trader B placed an order 37 | that buys 100 BTS at 0.105 USD per BTS, the two order will match at 0.105 USD 38 | per BTS, so A will pay 100 BTS and get 10.5 USD, B will pay 10.5 USD and get 39 | 100 BTS. 40 | 41 | While not strictly a bug, this behavior is unexpected and irritating for users. 42 | 43 | # Rationale 44 | 45 | Matching orders at the maker price, with margin calls being inlined in the 46 | order book, is an easy to understand rule and matches user expectations, 47 | see [bitshares-core 48 | issue #338](https://github.com/bitshares/bitshares-core/issues/338). 49 | 50 | There is a parameter in price feed named MSSR, which stands for "maximum short 51 | squeeze ratio". Maker price of margin call orders is MSSP, which stands for 52 | "maximum short squeeze price", is calculated as `feed_price / MSSR`. 53 | Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per 54 | collateral". 55 | 56 | Currently a black swan event will occur when the call order with least 57 | collateral ratio is going to be matched below 100% collateral ratio price 58 | (name it `100CRP`). Because the call order will be matched with incoming limit 59 | order at limit order's price (taker price), 60 | which can be higher or lower than 100CRP, so even if MSSP is below 100CRP, 61 | an incoming taker limit order may or may not trigger a black swan. 62 | So it makes sense to check if a black swan event will occur every time when a 63 | limit order is created. 64 | 65 | After the behavior changed to always match at maker price, when MSSP is below 66 | 100CRP, an incoming taker limit order will always trigger a black swan event. 67 | So it makes sense to trigger the black swan event when MSSP is below 100CRP 68 | rather than waiting for an incoming limit order. That means it's no longer 69 | needed to check for black swan event when a limit order is created. 70 | Since checking for black swan event is somehow expensive, we'll gain a side 71 | benefit on performance with the change. 72 | 73 | # Specifications 74 | 75 | Matching between a limit order and a call order is done in 76 | `check_call_orders(...)` function of `database` class, price of limit order 77 | is always used. It need to be changed to use MSSP when the call order is maker. 78 | 79 | When triggering a black swan event when MSSP is below 100CRP, 80 | sometimes the short 81 | position with least collateral ratio may still have more than 100% collateral 82 | ratio. In this case, the global settlement price is 100CRP but not the actual 83 | collateral ratio of the short position with least collateral ratio. 84 | This is current behavior, it's fair, no need to change. 85 | 86 | # Discussion 87 | 88 | It might seem unfair on the shorter to match at MSSP even if the incoming order 89 | specifies a better price. However, in a rationally acting market users will not, 90 | in the presence of margin calls, create limit orders below the MSSP. 91 | Effectively the new rule doesn't change this situation. 92 | 93 | # Summary for Shareholders 94 | 95 | [to be added if any] 96 | 97 | # Copyright 98 | 99 | This document is placed in the public domain. 100 | 101 | # See Also 102 | 103 | * https://github.com/bitshares/bitshares-core/issues/338 104 | * https://bitsharestalk.org/index.php?topic=25926.0 105 | -------------------------------------------------------------------------------- /bsip-0033.md: -------------------------------------------------------------------------------- 1 | BSIP: 0033 2 | Title: Maker Orders With Better Prices Take Precedence 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-17 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/625, 8 | https://github.com/bitshares/bitshares-core/issues/453 9 | Replaces: - 10 | Worker: 1.14.94 11 | 12 | # Abstract 13 | 14 | Currently, in BitShares, under certian circumstances, a taker order may be 15 | matched with a maker order which is not "on the top" of the order book. 16 | This behavior is unexpected and irritating for users. 17 | 18 | This BSIP proposes a principle: always match taker orders with maker orders 19 | with the best prices (aka on the top of the order book) first. 20 | 21 | # Motivation 22 | 23 | As expected, when matching taker limit orders with maker limit orders, the maker 24 | limit orders with better prices will always be matched first. 25 | 26 | For example, if trader A has a limit order selling 100 BTS at 27 | 0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, 28 | which means B's limit order has a better price for the opposite side to buy. 29 | Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, B's 30 | limit order will take precedence, A's limit order won't be matched. 31 | 32 | However, when there are (maker) margin call orders in the market which have met 33 | the requirements that to be matched (able to be margin called), they always 34 | take precedence over the (maker) limit orders on the same side, no matter 35 | whether the limit orders provided better price. 36 | 37 | For example, if trader A's margin call order is selling 100 BTS at no less than 38 | 0.1 USD per BTS, trader B has a limit order selling 100 BTS at 0.09 USD per BTS, 39 | which means B's limit order has a better price for the opposite side to buy. 40 | Now if trader C placed an order that buys 10 BTS at 0.105 USD per BTS, A's 41 | margin call order will take precedence, B's limit order won't be matched. That 42 | means C is forced to "buy high" when have chance to "buy low", which is 43 | unexpected. 44 | 45 | Users have been confused by this behavior, as discussed in [bitshares-core 46 | issue #625](https://github.com/bitshares/bitshares-core/issues/625) and other 47 | threads. 48 | 49 | Another scenario is described in [Bitshares-core 50 | issue #453](https://github.com/bitshares/bitshares-core/issues/453) 51 | that sometimes a taker margin call order may be matched with a maker limit order 52 | which is not on the top of the order book. This can be seen as a bug. 53 | 54 | # Rationale 55 | 56 | Always matching taker order (e.g. a buy) with a maker order which offered best 57 | price (aka lowest ask), is a simpler rule which most users would understand 58 | easily. 59 | 60 | There is a parameter in price feed named MSSR, which stands for "maximum short 61 | squeeze ratio". Maker price of margin call orders is MSSP, which stands for 62 | "maximum short squeeze price", is calculated as `feed_price / MSSR`. 63 | Note: `feed_price` here is in terms of debt/collateral, aka "how much debt per 64 | collateral". 65 | 66 | That said, the price that margin call orders are offering is MSSP. The prices 67 | those limit orders are offering are the limit prices. 68 | 69 | When placing a limit (e.g. buy) order with a price beyond the lowest sell, 70 | the order is expected to "walk the book", matching each order on the opposite 71 | side in turn, at that order's price, until the new limit order is completely 72 | filled, or there is no more sell order matching its price. 73 | 74 | To meet the expectation, 75 | * firstly, we need to match the limit buy order with the limit sell orders 76 | whose prices are lower than MSSP and prices can match the new order; 77 | * then, if the new limit buy order hasn't been completely filled, match it with 78 | the margin calls if MSSP can match the new order's price; 79 | * then, if the new limit buy order still hasn't been completely filled, match it 80 | with the rest sell orders until it's completely filled or no more sell order 81 | matching its price 82 | 83 | 84 | # Specifications 85 | 86 | ## Matching a taker limit order 87 | 88 | New limit order is being processed in `apply_order(...)` function of `database` 89 | class. 90 | 91 | Currently, in the function, firstly call orders will be checked and matched. 92 | After that, limit orders on the opposite side will be checked and matched. 93 | 94 | Need to change the logic to: 95 | 1. firstly, sort the limit orders on the opposite by `price`, best price first, 96 | end at MSSP; check them one by one, calls `match(...)` function until the 97 | return value is not `2` which means the new order is completely filled; 98 | 2. if reach the end (MSSP), which means the new order is still unfilled, 99 | call `check_call_orders(..)` function or an equivalent; 100 | 3. check if `new_order_object` still exist, if yes, redo step one but set the 101 | maximum possible price of the market as end price. 102 | 103 | ## Matching taker margin call orders 104 | 105 | For [bitshares-core 106 | issue #453](https://github.com/bitshares/bitshares-core/issues/453), 107 | in `check_call_orders(...)` function of `database` class, 108 | iterator `limit_itr` will move forward when variable `filled_limit` is `true`. 109 | `filled_limit` will be set to `true` when a limit order get completely filled. 110 | However, since `filled_limit` is declared out of the `while` block, 111 | it doesn't get reset to `false` after `limit_itr` moved forward. That means 112 | after the first limit order get completedly filled, `filled_limit` will always 113 | be `true`, so `limit_itr` will always move forward no matter whether *current* 114 | limit order got completedly filled, so a taker call order may match 115 | with a limit order that is not on the top of the order book. 116 | 117 | To fix this, need to change the code to make sure `limit_itr` always references 118 | the limit order on the top of the order book when dereferencing. 119 | 120 | # Discussion 121 | 122 | [to be added if any] 123 | 124 | # Summary for Shareholders 125 | 126 | [to be added if any] 127 | 128 | # Copyright 129 | 130 | This document is placed in the public domain. 131 | 132 | # See Also 133 | 134 | * https://github.com/bitshares/bitshares-core/issues/625 135 | * https://github.com/bitshares/bitshares-core/issues/453 136 | * https://bitsharestalk.org/index.php?topic=25926.0 137 | -------------------------------------------------------------------------------- /bsip-0034.md: -------------------------------------------------------------------------------- 1 | BSIP: 0034 2 | Title: Always Trigger Margin Call When Call Price Above Or At Price Feed 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-18 7 | Discussion: https://github.com/bitshares/bitshares-core/issues/606 8 | Replaces: - 9 | Worker: 1.14.95 10 | 11 | # Abstract 12 | 13 | Currently, in BitShares, a short position may be margin called only when both 14 | two requirements are met: 15 | * call price is above or equal to median price feed 16 | * no limit order on the book is buying collateral with price higher than the 17 | short position's call price 18 | 19 | This behavior has led to certain confusion and anger among market participants. 20 | 21 | This BSIP proposes a new behavior to improve the situation: drop the second 22 | requirement, trigger margin call when the first requirement is met. 23 | 24 | # Motivation 25 | 26 | To avoid ambiguity, in this article, all prices are in terms of 27 | `debt asset / collateral asset`, aka how much debt asset per collateral 28 | asset. A bid is an order to buy collateral asset with debt asset. 29 | 30 | Generally, a short position may be margin called when its collateral ratio is 31 | below or equal to maintenance collateral ratio (MCR). 32 | 33 | However, to calculate collateral ratio, a fair collateral price is needed. 34 | 35 | In BitShares, there are two data sources can be used to decide the fair 36 | collateral price: 37 | * the internal market 38 | * the price feeds 39 | 40 | Currently, both data sources are used. Specifically, collateral price is decided 41 | as the higher one between the highest bid price on the internal market and the 42 | median price feed. That said, when a short position's collateral ratio has 43 | fallen to below or equal to MCR according to median price feed (in this case, 44 | call price of the short position is above or equal to median price feed), if 45 | there is a bid on the market with high price, the short position won't be margin 46 | called. 47 | 48 | This mechanism has led to certain confusion and anger among market participants. 49 | * there are often orders with overlapping price on the book but didn't fill 50 | * there are often short positions selling collaterals with low prices, but 51 | traders are unable to buy at those prices 52 | * it often causes borrowers to sell collaterals at a low price when have chances 53 | to sell at higher price 54 | * market manipulators / arbitrage traders have more chances to force borrowers 55 | to sell collaterals at lower price 56 | 57 | This BSIP effectively proposes a new behavior: derive the fair collateral price 58 | only from price feeds. 59 | 60 | # Rationale 61 | 62 | Since price feeds are provided by a set of chosen producers, the median price 63 | feed is usually considered trustworthy. On the other hand, instant market 64 | price is not as reliable, especially for the markets with poor depth, so it's 65 | a rather limited supplement for calculating collateral price. 66 | 67 | At this moment, changing the rule to only use median price feed will clear away 68 | the confusion the end users may have, while still keeping the derived collateral 69 | price fair to an extent. 70 | 71 | After this change is done, placing a new limit order will no longer trigger a 72 | margin call, cancelling a limit order or expiring a limit order will no longer 73 | trigger a margin call as well, that means we don't need to check for new margin 74 | calls nor black swan events in those scenarios, so we'll gain a side benefit on 75 | performance. 76 | 77 | # Specifications 78 | 79 | In `check_call_orders(...)` function of `database` class, when matching a call 80 | order with a limit order, there is a check: 81 | `if( match_price > ~call_itr->call_price )`, when the result is `true`, 82 | processing will be ended and `margin_called` will be returned. 83 | Need to skip the check and the following `return` action. 84 | 85 | In `do_apply(...)` function of `limit_order_cancel_evaluator` class, and 86 | similar code blocks after a limit order object is removed, no longer need to 87 | call `check_call_orders(...)` function of `database` class. 88 | 89 | # Discussion 90 | 91 | [to be added if any] 92 | 93 | # Summary for Shareholders 94 | 95 | [to be added if any] 96 | 97 | # Copyright 98 | 99 | This document is placed in the public domain. 100 | 101 | # See Also 102 | 103 | * https://github.com/bitshares/bitshares-core/issues/606 104 | * https://bitsharestalk.org/index.php?topic=25926.0 105 | -------------------------------------------------------------------------------- /bsip-0036.md: -------------------------------------------------------------------------------- 1 | BSIP: 0036 2 | Title: Remove expired price feeds on maintenance interval 3 | Author: oxarbitrage 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-22 7 | Discussion: https://bitsharestalk.org/index.php?topic=25996.0 8 | Replaces: - 9 | Worker: 1.14.97 10 | 11 | # Abstract 12 | 13 | Currently, expired bitasset feeds remain in the blockchain forever. The only way to get them erased is if operation `update_feed_producers` is called with new publishers on the asset. At this call, and only at this case, old publisher feeds will be deleted from the blockchain. If this operation never occurs or if it occurs maintaining some or all of the same publishers feeds will not be removed. 14 | 15 | Some examples of this are the followings, where we can see feeds from 2015: 16 | 17 | - http://open-explorer.io/#/objects/2.4.9 - HKD 18 | - http://open-explorer.io/#/objects/2.4.21 - USD 19 | - http://open-explorer.io/#/objects/2.4.10 - RUB 20 | - etc. 21 | 22 | This BSIP proposes a protocol change to remove expired feeds at maintenance time. 23 | 24 | # Motivation 25 | 26 | Improve performance of the bitshares-core. 27 | 28 | 29 | # Rationale 30 | 31 | The proposed change only affects the feed price when the feed expiration time is increased. This rarely happens, if ever, so in practice the effect on pricing is negligible. The savings in performance however, is not. 32 | 33 | # Specifications 34 | 35 | As mentioned in the abstract feeds stay in the blockchain forever unless `asset_update_feed_producers_evaluator::do_apply` is called. 36 | 37 | The BSIP proposes to remove expired feeds at maintenance time by adding feed cleanup code at `db_main.cpp`. 38 | 39 | Solution is not that simple, `asset_update_bitasset_operation` can change `feed_expiration_time` and `minimum_feeds` required for the asset. 40 | 41 | If a feed is expired and the `feed_expiration_time` changes, expired feeds may became valid, similar if `minimum_feeds` (required to calculate the median) is increased, older feeds may became valid and used by the core market engine if available. 42 | 43 | This scenario actually happened in the past and that is the reason the change will fail unless a hardfork protection is added. 44 | 45 | ## The proposed solution 46 | 47 | Goal is to remove expired feeds in a safe manner. To do this we need to keep current behavior before hardfork date and only remove feeds at maintenance intervals after the hardfork. This will allow the chain to synchronize and start the cleanup at a point where all the feeds are valid, safely being able to remove them an continue clean from that time on. 48 | 49 | This a permanent hardfork, code before hardfork date will work one way(current behavior) and after date new code will work different making the feed cleanup at maintenance times. 50 | 51 | Feed cleanup code will only be executed after proposed hardfork date, at the first maintenance interval after date old feeds will be removed, node will not be able to use them anymore as they will not be available in the database. 52 | 53 | If `asset_update_bitasset_operation` is called before hardfork operation will be normal as it is currently is now. 54 | 55 | If `asset_update_bitasset_operation` is called after hardfork and increases the `minimum_feeds` while they are not enough feeds `update_median_feeds()` will set a null feed. This is current `asset_update_bitasset_operation`, no need to make any change in the operation. 56 | 57 | 58 | # Discussion 59 | 60 | https://bitsharestalk.org/index.php?topic=25996.0 61 | 62 | # Summary for Shareholders 63 | 64 | [to be added if any] 65 | 66 | # Copyright 67 | 68 | This document is placed in the public domain. 69 | 70 | # See Also 71 | 72 | * https://github.com/bitshares/bitshares-core/issues/518 73 | * https://github.com/bitshares/bitshares-core/pull/598 74 | -------------------------------------------------------------------------------- /bsip-0037.md: -------------------------------------------------------------------------------- 1 | BSIP: 0037 2 | Title: Allow new asset name to end with a number 3 | Author: oxarbitrage 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2018-02-23 7 | Discussion: https://bitsharestalk.org/index.php?topic=25997.0 8 | Replaces: - 9 | Worker: 1.14.98 10 | 11 | # Abstract 12 | 13 | Currently, the bitshares-core do not allow asset creation that start or end with a numerical character. Creation of index style assets like `CRYPTO500` are not possible. 14 | 15 | This BSIP proposes a protocol change to allow number characters at the end of the created asset name. 16 | 17 | # Motivation 18 | 19 | Economical, enable more asset names to be created in the exchange. 20 | 21 | 22 | # Rationale 23 | 24 | No valid reason was found until now about why this is not allowed. The creation of index style assets will bring new business to the exchange. 25 | 26 | # Specifications 27 | 28 | Restriction in asset names are detailed in `asset_ops.cpp`: 29 | 30 | ``` 31 | /** 32 | * Valid symbols can contain [A-Z0-9], and '.' 33 | * They must start with [A, Z] 34 | * They must end with [A, Z] 35 | * They can contain a maximum of one '.' 36 | */ 37 | ``` 38 | 39 | BSIP proposes to change third rule to: 40 | 41 | `They must end with [A, Z0-9]` 42 | 43 | As file where the changes are needed(`asset_ops.cpp`) do not have access to the database, we are unable to use `head_block_time()` to create the hardfork guard. 44 | 45 | The process is more complicated and it is described as follows:(quote from @abit in github ticker: https://github.com/bitshares/bitshares-core/issues/620#issuecomment-364803143): 46 | 47 | "To make the change, need to loose the validation code in `asset_ops.cpp`, add a hard fork guard code with original rule to asset_evaluator to make sure no rule change before the hard fork, add corresponding hard fork guard code in proposal_evaluator. After hard fork, those hard fork guard code can be safely removed." 48 | 49 | # Discussion 50 | 51 | https://bitsharestalk.org/index.php?topic=25997.0 52 | 53 | # Summary for Shareholders 54 | 55 | [to be added if any] 56 | 57 | # Copyright 58 | 59 | This document is placed in the public domain. 60 | 61 | # See Also 62 | 63 | * https://github.com/bitshares/bitshares-core/issues/620 64 | * https://github.com/bitshares/bsips/issues/52 65 | -------------------------------------------------------------------------------- /bsip-0039.md: -------------------------------------------------------------------------------- 1 | BSIP: 0039 2 | Title: Automatically approve proposals by the proposer 3 | Authors: Fabian Schuh 4 | Abit More 5 | Status: Draft 6 | Type: Protocol 7 | Created: 2018-03-20 8 | Discussion: https://github.com/bitshares/bitshares-core/issues/138 9 | https://github.com/bitshares/bsips/issues/71 10 | Worker: 11 | 12 | # Abstract 13 | 14 | On the BitShares Blockchain, proposals allow to gather signatures for a 15 | multisignature-setup by means of on-chain approvals. In contrast to 16 | other blockchains, these proposals are actually stored on the blockchain 17 | and automatically executed once the required amount of approvals has 18 | been reached. This allows participants of a multisignature-setup to 19 | exchange insufficiently signed transactions easily. 20 | 21 | However, when creating a new proposal, the proposer needs to manually 22 | approve his operation afterwards. This is not only inconvenient, but 23 | also costs and additional operation and thus a fee. 24 | 25 | This BSIP proposes a protocol change that enables the proposer of a 26 | proposal to automatically added herself as approved. 27 | 28 | # Motivation 29 | 30 | In the case of a simple 2-of-3 multisig-scheme, today's implementation 31 | forces us to have 3 operations stored on the blockchain: a) the proposal 32 | itself, and two approvals. 33 | 34 | The inconvenience and additional fee hinders adoption of this scheme and 35 | makes it unnecessary complicated. 36 | 37 | Due to lacking of an auto-approval feature, an ignorant user might fire a 38 | `proposal_create` operation to create a proposal and then immediately fire 39 | a `proposal_update` (i.e. approve) operation to approve the proposal. 40 | However, the final proposal ID is not known before the `proposal_create` 41 | operation is beyond the last irreversible block. So the user might 42 | inadvertently approve the wrong proposal. 43 | On Monday, 20th December 2018, [a node crash incident 44 | ](https://www.bitshares.foundation/announcements/2018-12-21-proposal-incident) 45 | was indirectly caused by this. 46 | 47 | # Rational 48 | 49 | Giving the proposer an option to automatically approve the proposal 50 | after creation solves the issue. 51 | 52 | If the proposer is not part of the multisig-setup, having him approve 53 | the proposal automatically does not affect the validity of the proposal 54 | itself. 55 | 56 | For backward compatibility, to avoid breaking existing applications, 57 | It's good to keep the default behavior. 58 | 59 | # Specifications 60 | 61 | Add an extension to the `proposal_create_operation` that let the proposer 62 | define whether to auto-approve the proposal after creation. If the 63 | extension is not present, do not auto-approve. The extension can only be 64 | used after a scheduled protocol upgrade time. 65 | 66 | # Discussion 67 | 68 | By proposing an action, sometimes the proposer can be considered as an 69 | agreeing party, otherwise the proposal wouldn't have been created in 70 | the first place. Since sometimes the proposer doesn't want to approve 71 | immediately, it's better that she has an option to decide whether to 72 | auto-approve. 73 | 74 | # Non-technical Summary 75 | 76 | This BSIP proposes a minor modification that improves the process of 77 | using hierarchical account permissions and simplifies the use of 78 | multisig-setups with only minimal modifications. 79 | 80 | # Copyright 81 | 82 | This document is placed in the public domain. 83 | 84 | # See Also 85 | 86 | * https://github.com/bitshares/bitshares-core/issues/138 87 | * https://github.com/bitshares/bsips/issues/71 88 | * https://www.bitshares.foundation/announcements/2018-12-21-proposal-incident 89 | -------------------------------------------------------------------------------- /bsip-0041.md: -------------------------------------------------------------------------------- 1 | BSIP: 0041 2 | Title: Reduce MSSR of bitCNY from 1.1 to 1.05 3 | Author: Jerry Liu 4 | Status: Superseded 5 | Superseded-By: 0059 6 | Type: Informational 7 | Created: 2018-08-17 8 | Discussion: https://bitsharestalk.org/index.php?topic=26928.0 9 | Worker: 1.14.144 10 | 11 | ### **Abstract** 12 | We here propose to reduce the Maximum short squeeze ratio (MSSR) of bitCNY from 1.1 to 1.05, to lower the shorting incentive. 13 | 14 | ### **Motivation** 15 | BitShares is a financial system with leverage, here in the traders there are BTS longers and shorters, surely the traders are finding their chance to make profit in trading, if shorters can always find chance to make big profit by shorting BTS, that’s not a good news to BTS ecosystem, from the perspective of the whole BTS ecosystem consisted of DEX and smartcoin, we need to review the rules continually, while guaranteeing fairness and the risks always be released in time, we also need to try optimize the rules to encourage BTS longers, to provide enough incentive to make BTS ecosystem to grow up. 16 | 17 | 18 | ### **Rationale** 19 | Currently there are 2 key smartcoin parameters which are maintained by witnesses, they are MCR(Maintenance collateral ratio ) and MSSR(Maximum short squeeze ratio) , now MCR=1.75 and MSSR=1.1. 20 | 21 | When a debt position is margin called, the placed sell orders is at price feed price/MSSR, so MSSR determine the discount of collateral force selling the higher MSSR, the bigger the discount. 22 | 23 | So high MSSR benefits the filling of margin call sell orders and help to release risks rapidly, however at the same time, high MSSR means buying margin call orders is with big discount, so it encourage BTS shorters to accumulate smartcoins and wait or even try to make margin call happen and get cheaper collateral. This does not do good to the ecosystem grow up. 24 | 25 | We need to release risks rapidly while margin call happen, we also need to try to lower the shorting incentive, so we need a balance, what a MSSR is appropriate depend on the liquidity of the market and also some other factors. 26 | 27 | bitCNY have a very good liquidity, BTS/bitCNY pair in DEX is the pair with highest BTS volume on the earth, after in 19th July the hard fork activated the target CR feature, the sell pressure comes from margin called orders decreased greatly, we are sure that the for bitCNY black swan has very very little chance to happen, it’s the time to reduce MSSR to push bitCNY ecosysm move forward. 28 | 29 | ### **Specification** 30 | Witnesses adjust the MSSR of bitCNY from 1.1 to 1.05 while publishing feed price. 31 | 32 | ### Discussion 33 | #### Will this change be implemented to bitUSD and other smartcoins? 34 | This time, no! bitUSD and other smartcoins has a much lower liquidity than bitCNY, a high MSSR need to be kept to guarantee the rapid settlement of margin called dept positions. 35 | 36 | #### How to make sure a strong consensus is reached? 37 | China community has discussed about this change for years, however, target CR feature + good bitCNY liquidity make current time the good time to do the change, in the forum thread, about 70% of the voters support this change, if necessary, a opinion survey worker proposal will be created to collect stake based opinion. 38 | As MSSR comes from witness publishing, so when BTS community reach a strong consensus to do the change, we need witnesses to apply the change based on the community consensus 39 | 40 | ### **Summary for Shareholders** 41 | Reduce shorting incentive while guaranteeing fairness and safe is an important logic for the ecosystem to evolve. 42 | 43 | ### **Copyright** 44 | This document is placed in the public domain. 45 | -------------------------------------------------------------------------------- /bsip-0042.md: -------------------------------------------------------------------------------- 1 | BSIP: 0042 2 | Title: Adjust price feed to influence trading price of SmartCoins 3 | Author: Abit More 4 | Status: Up for voting 5 | Type: Protocol 6 | Created: 2018-08-22 7 | Workers: 1.14.118 (pro), 1.14.119 (con) 8 | 9 | # Abstract 10 | 11 | We here propose to dynamically adjust price feed in order to influence trading 12 | price of smart coins to achieve tighter peg. 13 | 14 | This BSIP is constantly evaluated in terms of being accepted or rejected,see the last section *Constant voting evaluation* for details. 15 | 16 | # Motivation 17 | 18 | To get mass adoption, it's better that the SmartCoins can peg to targets more 19 | tightly. E.G. bitUSD pegs more tightly to Fiat USD. 20 | 21 | # Rationale 22 | 23 | When BTS is in a downtrend, the SmartCoins are always being traded at a 24 | premium; when BTS is in a uptrend, the SmartCoins tend to be traded with a 25 | discount. Here is a chart showing historical trading price of bitUSD: 26 | https://coinmarketcap.com/currencies/bitusd/ 27 | 28 | Typically a premium is around 10%, and a discount is around 5%. Although some 29 | people think the numbers are not very large, other people think they're too 30 | large. In this BSIP we aim to reduce the numbers. 31 | 32 | Trading price of a SmartCoin is influenced by 33 | * underlying value guaranteed by collateral; 34 | * demand vs supply. 35 | 36 | ## Downtrend and premium 37 | 38 | When BTS is in a downtrend, before a black swan event, supplies of SmartCoins 39 | are squeezed, while the underlying value is still guaranteed if price feeds are 40 | around real trading price, thus trading price of the SmartCoins will be pushed 41 | up. 42 | 43 | If we slightly adjust the price feed, thus slightly loose the guarantee on the 44 | underlying value, hopefully we can push the trading price of SmartCoins towards 45 | par. Since adjusting price feed affects supply as well, ideally we don't need to 46 | adjust much to achieve the goal. 47 | 48 | Other options include decreasing MCR to stimulate supply, or decreasing MSSR to 49 | suppress demand. 50 | 51 | ### Negative feedback 52 | 53 | Actually we don't know what's the best offset to be applied to the inputs, but 54 | we can adopt a negative feedback approach. When adjusting the inputs, keep an 55 | eye on the result (trading price of SmartCoins). If the adjustment is in the 56 | correct direction, the price should move towards par. If the price moved too 57 | little, we adjust more; if the price moved too much, we adjust less. Finally 58 | this will lead to a stable result. 59 | 60 | We may consider setting a hard limit on the offset which may make us feel safer. 61 | Actually, to be safe, we do need to start with a small offset, and adjust little 62 | by little. Since it's expected that the best offset will be figured out by the 63 | negative feedback mechanism, a preset limit may impact the mechanism negatively. 64 | A few witnesses publishing too far away offset doesn't harm much because 65 | they won't move the median much. In addition, stake holders may vote down 66 | perceived bad actors. 67 | 68 | ### Risks 69 | 70 | All the adjustments (price feed, or MCR, or MSSR) in a downtrend actually looses 71 | requirement of collateral ratio, so it seems it will increase the possibility 72 | of black swan events. This is actually the most contraversial part of this BSIP. 73 | 74 | The counter argument is about liquidity. As we can see, even without the 75 | adjustments, black swan events have occurred on bitHKD, bitSGD and some other 76 | SmartCoins due to poor liquidity. In contrast, bitCNY, bitUSD and etc have 77 | survived due to good liquidity. With the adjustments, hopefully we'll have 78 | better adoption, which means better liquidity in the markets, so possibility 79 | of black swan events would likely decrease. 80 | 81 | ### Guarantee of value 82 | 83 | Adjusting price feeds impacts force settlements. Specifically, a user will 84 | likely get less by force settling when the price feed is adjusted. This lead 85 | to an argument says it breaks guarantee of SmartCoins' value. 86 | 87 | The counter argument is also liquidity. With good liquidity, users should buy 88 | from market rather than force settling. It's up to UI to guide users for better 89 | experience. If a user has a large volume to trade, she has to be patient, 90 | since even go the force settlement approach she will likely encounter the 91 | volume limitation as well. 92 | 93 | ### Margin call price 94 | 95 | Actual price (in FIAT) when buying into a margin call would be unchanged, 96 | because the adjustment will shift trading price of SmartCoins but not BTS. 97 | It's expected that margin calls will be less though. 98 | 99 | ### User experience changes 100 | 101 | Currently, GUI shows median price feed on the market page. By looking at the 102 | price, 103 | people know what price BTS is trading around. Then people can check lastest 104 | trading price of BTS / SmartCoin pairs, to know how much premium or discount 105 | that the SmartCoins are trading at. 106 | 107 | After applied the adjustments on price feeds, the median price feed showing 108 | on market page of GUI will no longer mean trading price of BTS, instead, it 109 | will mean a somewhat "guiding price" for SmartCoin production. People may get 110 | confused especially in the beginning of applying the adjustments. 111 | 112 | On the other hand, after applied the adjustments, hopefully SmartCoins will 113 | be traded on par, so latest trading price of BTS / SmartCoin pairs will 114 | indicate trading price of BTS. 115 | 116 | It's up to the GUI development team to optimize the GUI for better user 117 | experience. 118 | 119 | 120 | ## Uptrend and discount 121 | 122 | When BTS is in a uptrend, usually SmartCoins are oversupplied which results in 123 | devaluation. Ideally, to reduce supply, the best approach is to increase MCR. 124 | However, at this moment, there is a bug in BitShare-Core so we can't adjust MCR 125 | freely (more info is here: 126 | https://github.com/bitshares/bitshares-core/issues/1270). Before the bug is 127 | fixed, we can adjust price feed instead, similar to downtrend, with negative 128 | feedbacks, but in opposite direction. 129 | 130 | Note: when adjusting price feed in a uptrend, we should set a fair force 131 | settlement offset at same time, see [BSIP 16](bsip-0016.md) for more info. 132 | 133 | 134 | # Specification 135 | 136 | When witness publishing a price feed, after got price of BTS from exchanges 137 | (assuming it's `P`), check trading price of the publishing SmartCoin, 138 | adjust `P` with an algorithm. 139 | 140 | To be safe, the algorithm should start with a small offset, or a value near 141 | the median, and adjust the offset little by little. 142 | 143 | The algorithm should implement negative feedback, 144 | that said, it should track historical adjustments and historical differences 145 | on trading prices of SmartCoins, and make new adjustments accordingly. 146 | 147 | We don't force all witnesses to use a same algorithm, instead, witnesses are 148 | encouraged to implement different algorithms for same goal. 149 | 150 | We also don't set a hard limit about how much the offset should be within, in 151 | order to let the negative feed back mechasim find the best result by itself. 152 | Witnesses should make their own decisions on whether to set a hard limit and 153 | how much should it be if need to set one, generally, to reduce impacts caused 154 | by bugs. 155 | 156 | It will be good to apply the change to bitCNY first, which has much better liquidity 157 | than other smartcoins. After witnesses and community learned enough in the process 158 | it can be also applied to bitUSD. 159 | 160 | # Discussion 161 | 162 | - https://bitsharestalk.org/index.php?topic=26948.0 163 | - https://bitsharestalk.org/index.php?topic=26315.0 164 | - https://bitsharestalk.org/index.php?topic=26966.0 165 | 166 | # Summary for Shareholders 167 | 168 | The peg of SmartCoin to the underlying asset is crucial to create trust for SmartCoin holders, in combination with a force settlement offset that is considered fair. This BSIP seeks to adress the issue of volatility with respect to the peg by allowing the witnesses to implement (within boundaries) their own price feed strategy that is targeted to uphold the peg and provide a fair force settlement offset. 169 | 170 | This is a crucial intrusion into the open market mechanics and is thus not a strict directive to the witnesses, furthermore this BSIP is constantly evaluated, and if it becomes rejected (see the next section), witnesses are bound to return to the former price feed mechanisms. 171 | 172 | # Constant voting evaluation 173 | 174 | This BSIP has a pro and a con worker and has an ever evaluated state of accepted and rejected. 175 | 176 | - **Accepted**: 177 | The pro worker is active in terms of receiving payout from the reserve pool AND its votes surpass the con worker. 178 | 179 | - **Rejected**: 180 | The pro worker is NOT active (is not receiving funds from reserve pool) OR the votes of the con worker surpass the pro worker. If the pro worker expires, this BSIP is also considered rejected. 181 | 182 | The earliest that this worker can become active is 7th September 2018. 183 | 184 | # Copyright 185 | 186 | This document is placed in the public domain. 187 | -------------------------------------------------------------------------------- /bsip-0043.md: -------------------------------------------------------------------------------- 1 | BSIP: 0043 2 | Title: Market fee sharing 3 | Authors: OpenLedgerApp 4 | Status: Installed 5 | Obsoletes: [BSIP-0004](bsip-0004.md) 6 | Type: Protocol 7 | Created: 2018-08-23 8 | Updated: 2018-10-19 9 | Discussion: https://github.com/bitshares/bsips/issues/102 10 | Worker: 11 | 12 | 13 | # Abstract 14 | 15 | When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. 16 | 17 | However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. 18 | 19 | An asset owner defines the **market_fee_reward_percent** in asset options - what percentage of the market fee he wants to share with the registrar. 20 | **market_fee** * **market_fee_reward_percent** goes the registrar. 21 | **market_fee** * (1 - **market_fee_reward_percent**) goes to the asset owner. 22 | 23 | Registrar splits the reward between itself and its referrers by defining **reward_percent**, which defines referrer's percentage. 24 | It is defined per each other using the already existing BitShares mechanism. 25 | 26 | Market fee reward is accumulated on the user account. 27 | 28 | Each user decides when he wants to claim the market fee reward and move it to their active balance. 29 | 30 | # Motivation 31 | 32 | To make promoting BitShares and bringing new users much more attractive to registrars and referrers by sharing UIAs and MPAs market fees with them. 33 | 34 | # Rationale 35 | When *fill_order_operation* executing at the moment of market fee calculation there will be calculate the reward for the registrar used the parameter **market_fee_reward_percent**. Then this **market_fee_reward_percent** of the market fee is split between the registrar and referrer according to the referrer_rewards_percentage, which is set up during the new account registration by registrar (please see the parameters for *register_account*). 36 | 37 | # Specifications 38 | Market fee rewards accumulated on special vesting balances. 39 | 40 | ## **market_fee_reward_percent** asset option 41 | Percent of market fee that will be paid to buyer's registrar. Set by asset owner. 42 | if **market_fee_reward_percent** = 0 or absent - the old mechanism is used. Market fees are accumulated in the asset and can be claimed. 43 | 44 | ## **market_sharing_whitelist** asset option 45 | An optional list of accounts (configurable by the asset owner) could provide increased control over who is eligible to get market rewards. 46 | If whitelist empty or absent - there is no filtering. This means that everyone is in the whitelist by default if it is empty. 47 | 48 | ## graphene::chain::database modifications 49 | **pay_market_fees(seller, recv_asset_object, receives_amount)** - Split pay to asset owner fee, registrar fee and referrer fee. If the registrar is not in the **market_sharing_whitelist**, *split_pay* will not happen and the entire fee goes to Asset owner. 50 | **calculate_market_fee(trade_asset, trade_amount)** - Calculate value for previous function. 51 | **fill_limit_order(order, pays, receives, cull_if_small, fill_price, is_maker)** - Append hardfork (HARDFORK_REWARD_TIME) check. Use old or new version of *pay_market_fees()* function. 52 | 53 | ## asset_create_evaluator, asset_update_evaluator modifications 54 | Append hardfork (HARDFORK_REWARD_TIME) check. Validate additional asset options. Apply additional asset options (**market_fee_reward_percent**, **market_sharing_whitelist**) 55 | 56 | # Description 57 | 58 | # Summary for Shareholders 59 | The new modification - market fee sharing - will allow to bring in new clients for BitShares by making it financially lucrative for registrars and referrers. This modification is interesting mostly so asset owners and registrars/referrers. 60 | 61 | # Copyright 62 | This document is placed in the public domain. 63 | 64 | # See Also 65 | https://github.com/bitshares/bitshares-core/issues/1268 66 | 67 | https://github.com/bitshares/bitshares-core/pull/1419 68 | -------------------------------------------------------------------------------- /bsip-0045.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BSIP: 45 3 | Title: Introduce 'allow use as bitasset backing collateral' flag/permission to assets 4 | Authors: @grctest 5 | Status: Draft 6 | Type: Protocol 7 | Created: 07/10/2018 8 | Discussion: https://github.com/bitshares/bsips/issues/80 9 | Replaces: N/A 10 | Superseded-By: N/A 11 | Worker: N/A 12 | ``` 13 | --- 14 | 15 | # Abstract 16 | 17 | It's currently possible to impose new asset settings through MPA encapsulation without the permission of the backing asset's 'asset owner'. 18 | 19 | This BSIP proposes to introduce a new asset permission/flag which enables the asset owner to enable|prevent MPA encapsulation. 20 | 21 | # Motivation 22 | 23 | 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'. 24 | 25 | # Rational 26 | 27 | By providing asset owners this functionality, we can improve asset owner confidence in the finality of their configured asset settings. 28 | 29 | # Specifications 30 | 31 | ## Create new 'allow use as backing collateral' flag/permission 32 | 33 | 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. 34 | 35 | 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. 36 | 37 | Non applicable assets (PM & twice nested MPA) would prevent the flag from being enabled. 38 | 39 | Existing assets currently not used as backing collateral could be set to disabled by default. 40 | 41 | # Discussion 42 | 43 | ## Consequences of MPA encapsulation 44 | 45 | * Removal/Bypassing of market fees (if enabled) 46 | * Re-implementation of confidential transfers (if disabled) 47 | * Evasion of whitelist/blacklist (both user & market lists) 48 | * Preventing the issuer from transfering the asset back to themselves (Can't transfer backing collateral back to yourself) 49 | * Remove backing asset issuer from transfer approval provess. 50 | 51 | ## Committee configuration 52 | 53 | 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). 54 | 55 | ## Enabling the flag grants permisson for all 56 | 57 | Currently you can perform MPA encapsulation without involving the asset owner, this could introduce conflict between the two asset owners. 58 | 59 | 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. 60 | 61 | If it's disabled, that's a clear indication that the asset owner doesn't want it used as backing collateral. 62 | 63 | ## How to configure assets held by null-account? 64 | 65 | 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? 66 | 67 | ## Proposed UI changes 68 | 69 | 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. 70 | 71 | --- 72 | 73 | # Summary for Shareholders 74 | 75 | * Introduces new asset owner permissions. 76 | * Helps mitigate negative MPA encapsulation consequences, improving gateway regulatory compliance capability? 77 | * 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. 78 | 79 | # Copyright 80 | 81 | This document is placed in the public domain. 82 | 83 | # See Also 84 | 85 | N/A 86 | -------------------------------------------------------------------------------- /bsip-0059.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | BSIP: 59 4 | Title: Adjustment of MSSR and MCR through voting 5 | Authors: Jerry Liu 6 | Status: Draft 7 | Type: Informational 8 | Created: 2019-02-15 9 | 10 | 11 | 12 | # Abstract 13 | This BSIP define a process to change MSSR and/or MCR for one specific smartcoin through poll voting. 14 | 15 | # Motivation 16 | In smartcoin system, debt and supply are the 2 sides of the same thing, increasing supply also means increasing debt, paying debt also means reducing supply, to make the smartcoin peg well and make the supply match the market demand is always the system goal. 17 | 18 | We have done a lot to remove the unnecessary punishment to margin called debt position owners - Target CR, MSSR reduction, Global Settlement Protection, all these is to add more energy to the smartcoin system. 19 | 20 | MSSR and MCR are the 2 key parameters in smartcoin system, MCR has big impact on smartcoin supply, MSSR has big impact on smartcoin premium and also the supply. 21 | 22 | Now the 2 parameters are published by witnesses, generally speaking, witnesses publish MSSR&MCR following the consensus of the stakeholders, at the begin of BTS2.0, MSSR=1.1 and MCR=1.75 applied to all the smart coins, no changed has beed done until several weeks ago MSSR has been changed to 1.05 for bitCNY through BSIP41. 23 | 24 | We can expect that in the future it's also necessary to change MSSR or/and MCR, some more complex proposal - dynamic MCR and MSSR are also discussed, before this advanced solution can get sufficient consensus and be available, we need to define a common process to change MSSR or/and MCR through voting. 25 | 26 | # Rationale 27 | Here bitCNY is an example, the logic is same for all the smartcoins. 28 | 29 | Definition: ratio = P[bitCNY/CNY] - 1 30 | 31 | bitCNY discount = -ratio while ratio<0 32 | 33 | bitCNY premium = ratio while ratio>0 34 | 35 | While BTS price moves from high to low, bitCNY premium moves from low to high, the whole market condition can be divided into 4 phases: 36 | 37 | 1.bitCNY discount > force settlement offset (current value 2%) 38 | Because of the force settlement, even bitCNY enter into this phase it will soon get out. 39 | 40 | 2.bitCNY discount < force settlement offset & bitCNY premium < (MSSR-1)   41 | In this phase, the margin call orders will be eaten immediately after it is generated, risk will not be accumulated and bitCNY peg well, this is the ideal phase. 42 | 43 | 3.bitCNY premium > (MSSR-1)  44 | In this phase the margin call orders will stay there without being eaten, global settlement price will not drop while the feed price drop, risk accumulate. 45 | 46 | 4.market price drop below the global settlement price 47 | While global settlement protection measure is implemented, global settlement will not happen, feed price will stop to drop following the market price, if BTS price continue to drop, bitCNY will devalue. 48 | 49 | It’s best for bitCNY to be always in phase 2, the system should always avoid bitCNY to fall in phase 4 in comparatively high BTS price. 50 | If bitCNY fall in phase 3 for long time, it will be good to reduce the premium by reducing MSSR. 51 | Decreasing of MCR will help to supply more bitCNY and help bitCNY to jump from phase 3 to phase 2. 52 | 53 | ### Specifications 54 | In current Bitshares mechanism the witnesses are elected by voters. The values of MSSR and MCR for any smart asset issued by the BitShares Committee (i.e. bitAssets) are published by elected witnesses and then used by the blockchain to calculate the median value of the MSSR and MCR settings. 55 | 56 | The above mechanisms will not be changed in this BSIP. This BSIP just establish a formal process to reach consensus on MSSR/MCR value setting and convey the consensus to witnesses. 57 | 58 | Changes to MSSR/MCR will be decided on each smartcoin separately by voting, each time one change is issued 2 poll worker proposals will be created standing FOR and AGAINST the change. 59 | 60 | For example, to decide whether to reduce MSSR to 1.02 for bitCNY, 2 poll worker proposals will be created for voting: 61 | 62 | Poll-BSIP**-Reduce MSSR to 1.02 on bitCNY 63 | 64 | Poll-BSIP**-No Reduce MSSR to 1.02 on bitCNY 65 | 66 | If the voting confirm the change, committee will announce the change at least 3 days before the change is implemented by witnesses. 67 | 68 | As change to MCR is not available because of a bug, this BSIP will apply only to MSSR change until the bug is fixed. 69 | 70 | # Potential Risks 71 | Adjustment to one direction has both pros and cons. 72 | Decreasing of MCR will help to supply more smartcoins, but will also make the average collateral ratio more close to 1 and may increase the possibility to fall in phase 4. 73 | Decreasing of MSSR will help to reduce premium, but may also reduce the possibility for the margin called orders to be filled and increase the possibility to fall in phase 4. 74 | 75 | Although the proposed values for MSSR and MCR could be selected carefully to comply with the market status and to avoid the risk, there is no way to guarantee that they will work well enough. Voters will need to evaluate each setting that is proposed in a BSIP poll. 76 | 77 | # References 78 | [Suggestion on bitCNY rules update after BSIP42](https://bitsharestalk.org/index.php?topic=27522.0) 79 | 80 | # Summary for Shareholders 81 | It is important to define a process for the stakeholders to decide to change MSSR/MCR through voting, This can currently be achieved with the technical options that are available to the witnesses. 82 | 83 | # Copyright 84 | This document is placed in the public domain. 85 | -------------------------------------------------------------------------------- /bsip-0061.md: -------------------------------------------------------------------------------- 1 | BSIP: 0061 2 | Title: Operation to Update Limit Orders 3 | Authors: 4 | Nathan Hourt 5 | Status: Draft 6 | Type: Protocol 7 | Created: 2019-02-22 8 | Discussion: https://github.com/bitshares/bsips/issues/150 9 | 10 | # Abstract 11 | This BSIP proposes a new operation, `limit_order_update_operation`, which will allow direct modification of a limit order. This operation will be smaller to serialize than the cancel/create operation combination presently required to achieve the same result, as it must only store new field values rather than all field values. Moreover, the update operation will require lower processing and RAM consumption. In return for this reduction in consumption, the overall fee charged for an update operation can be set lower than the equivalent cancel/create combo, thus incentivizing market makers to keep freshly updated orders at the top of the books. 12 | 13 | # Motivation 14 | At present, the BitShares protocol does not allow direct modification of limit orders in the markets. Instead, to modify a limit order, the order must be canceled and and a new one created in its place. This results in greater-than-necessary overhead when updating a limit order, an action which is performed by market maker robots with great frequency (hundreds of times per day, per market). Additionally, the cancel/create combination requires payment of two fees, which has led to some pressure from market makers for BitShares to provide a cheaper mechanism for maintaining fresh order walls in the markets. 15 | 16 | # Rationale 17 | The specification below was chosen on the following criteria: 18 | - Minimal storage space for historical data (i.e. serialized operation size) 19 | - Cancel/create combination requires two distinct operations, and explicit restatement of all order parameters 20 | - Update operation requires only one operation, which elides all fields which are not being updated 21 | - Minimal processing 22 | - No deletion/construction is necessary, object is modified in place 23 | - Cancel/create requires two separate modifications of balances; update requires zero or one 24 | - Order matching is only triggered if order is moved past previous top of book 25 | - Minimal RAM consumption for undo storage 26 | - Object modification requires slightly less space than object deletion and creation 27 | - Balances and account statistics are not updated unless necessary, avoiding unnecessary undo storage 28 | 29 | # Specification 30 | A complete implementation of this BSIP is available for review [here](https://github.com/bitshares/bitshares-core/compare/develop...nathanhourt:issue-1604). 31 | 32 | The `limit_order_update_operation` contains the following fields: 33 | ```cpp 34 | asset fee; 35 | account_id_type seller; 36 | limit_order_id_type order; 37 | optional new_price; 38 | optional delta_amount_to_sell; 39 | optional new_expiration; 40 | 41 | extensions_type extensions; 42 | ``` 43 | 44 | This operation will have the following stateless validity checks: 45 | - Fee is positive 46 | - At least one of the optional update fields is not null 47 | - If `new_price` is not null, run its `validate` method 48 | - If `delta_amount_to_sell` is not null, check it is not zero 49 | 50 | Additionally, the following stateful checks will be applied during evaluation: 51 | - `seller` matches referenced order object's owner 52 | - If `new_price` is not null, check its assets match those in the referenced order 53 | - If `delta_amount_to_sell` is not null and positive, check it does not exceed seller's balance 54 | - If `delta_amount_to_sell` is not null and negative, check it does not exceed order's balance 55 | - Check if order is too small using the logic defined in `maybe_cull_small_order()` and reject the update if so 56 | - If `new_expiration` is not null, check it is in the future 57 | 58 | A single new evaluator is required, which shall check that the new field values are valid for the order being updated, and update the order and balances as necessary, then trigger order matching only if the price was modified such that the order has moved past the previous top-of-book order. 59 | 60 | No new indexes are required. No modifications to existing indexes are required. No new database objects are defined. No modifications to existing database objects are required. 61 | 62 | # Summary for Shareholders 63 | The changes proposed in this BSIP are easily implemented, and the only downside apparent to the author is the definition of a new operation type, which slightly increases the complexity of creating a new implementation of the BitShares protocol. Thus, the question must be considered, is the new operation of significant value to the community, and will it be used? 64 | 65 | The new operation is of greatest value to market makers, as these individuals typically run robots which must monitor the markets and maintain competitively priced orders on both sides of the market. These orders must be updated regularly, especially for BitAsset markets. The addition of an operation to modify limit orders will reduce the cost of market making, thus increasing the incentive for users to provide this service. Additionally, it reduces the requirements for processing and storing market maker activity. 66 | 67 | In conclusion, this BSIP proposes a very small modification to the protocol with minimal downside, and a meaningful upside for market makers and reduced requirements for all nodes which process the markets. 68 | 69 | # Copyright 70 | This document is created for the betterment of humanity and is hereby placed into the public domain. 71 | 72 | # Discussion 73 | A full implementation is available at: 74 | https://github.com/bitshares/bitshares-core/issues/1604 75 | 76 | #### Fee Calculation 77 | This operation is a simple object update operation; it does not allocate new resources nor command processing logic additional to that which was already expected by the pre-existing object. A limit order on the books is created with the expectation that it will either be matched, potentially several times, or canceled, and fees to cover this storage and processing are collected during order creation. Because this operation does not fundamentally change this scenario, it charges a simple, non-refundable processing fee, and does not interact with the refundable order creation fee. 78 | 79 | The limit order update operation may be used to "top up" an existing order and keep it on the books longer, possibly matching against more orders than would have been predicted when the order was created. This implies that for long-standing orders, the limit order update operation may constitute a discount over normal order creation, cancelation, and processing fees. Long-standing orders, however, are more valuable to the DEX than short-lived orders, as they promote market depth and high volume trading: market attributes which attract traders and more short-lived orders. The value added to the DEX as a whole by making it more economical for market makers to maintain long-standing orders significantly outweighs the discount the update operation affords to market makers; therefore, this proposal does not regard this discount on processing as detrimental to the blockchain as a whole. 80 | -------------------------------------------------------------------------------- /bsip-0062.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BSIP: 0062 3 | Title: Close margin position 4 | Authors: 5 | Stefan Schießl stefan.schiessl@blockchainprojectsbv.com 6 | Jerry Liu bitcrab@qq.com 7 | Status: Approved 8 | Type: Protocol 9 | Created: 2019-09-14 10 | Worker: 1.14.228 11 | ``` 12 | 13 | # Abstract 14 | Closing a short position comes with a risk of getting margin called if no spare funds are available to buy the long and reduce the debt to zero. This BSIP introduces a way to put the short position directly on the market. 15 | 16 | # Rationale 17 | Closing a short position with a healthy CR should come with no risk of getting margin called. Currently a user, who has no spare funds, has to take out collateral from the short position in order to put it on the market. Reducing the collateral increases the risk of margin call. This is especially cumbersome and risky if you want to close a position that has CR close to MCR (in that case you can only take out a small amount of collateral, sell it, reduce debt, repeat until position closed). 18 | 19 | # Specification 20 | Introduce a way that user can directly place orders to sell collateral in a margin position, and the received SmartCoins will be used to reduce the debt automatically. 21 | 22 | We introduce a direct collateral sell order and a manual margin call. Recommendation to the core team is to implement one of them for the upcoming hard fork, and the other one for the following one. 23 | 24 | ## Direct collateral sell order 25 | 26 | User needs to define the amount to sell and the amount to receive while placing the order. The amount to receive must be equal or less than the debt amount, and the price must be less than the current collateral ration times feed price 27 | (ensurance that the margin positions collatearl ratio will not be reduced after the filling of the sell orders). 28 | 29 | Remarks: 30 | 1. No creation fee refund when the order is cancelled. 31 | 32 | 2. The order should be cancelled automatically if the asset is globally settled. 33 | 34 | 3. The order should be cancelled automatically if the position is manually closed. 35 | 36 | 4. If the order wants to sell more collateral than it has left (due to margin called, force settled or debt position updated), only allow to fill this order up to the actually available collateral (this may be realized by shrinking the actual values in the limit_order object, or through calculation logic when trying to match). 37 | 38 | 5. If the order is asking for more than its debt (due to margin called, force settled or debt position updated), only allow to fill this order up to the actually needed debt (this may be realized by shrinking the actual values in the limit_order object, or through calculation logic when trying to match). 39 | 40 | 6. `fill_or_kill` can be set just like for a normal limit order 41 | 42 | 7. `expiration` must be defined 43 | 44 | ## Manual margin call 45 | User needs to specify the manual margin call price ratio (value must be positive, and a value of 1 represents the feedprice) that will be used to calculate the sell price depending the feed price, and a manual margin call will be created that follows the logic of a margin call, except that the price is calculated from the user-defined percent instead of MSSR. 46 | 47 | 48 | # Discussion 49 | Another process logic is also possible when a debt position is margin called or margin call orders change with close short orders,system check whether the margin call conflict with the close short orders via a defined logic, if yes than delete all the close short orders and place margin call orders, if not just place margin call orders without deleting the close short orders. 50 | 51 | This logic bring better user experience but also complexity. it is also a good choice if the complexity is acceptable from developer's perspective. 52 | 53 | # References 54 | * https://bitsharestalk.org/index.php?topic=28211.0 55 | * https://github.com/bitshares/bsips/issues/129 56 | * https://github.com/bitshares/bsips/issues/156 57 | 58 | # Copyright 59 | This document is placed in the public domain. 60 | 61 | # Voting outcome 62 | Approved since December 2019. 63 | ![image](https://user-images.githubusercontent.com/33128181/72417517-597a9e00-3779-11ea-9897-c1870a691eb3.png) 64 | 65 | 66 | -------------------------------------------------------------------------------- /bsip-0064.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BSIP: 64 3 | Title: Optional HTLC preimage length, HASH160 addition, and memo field 4 | Authors: John Jones , abitmore 5 | Status: Installed 6 | Type: Protocol 7 | Created: 2019-07-09 8 | Discussion: https://github.com/bitshares/bsips/issues/163 9 | ``` 10 | 11 | Abstract 12 | =================== 13 | This BSIP proposes three changes to Hashed Time Lock Contracts (HTLC) defined in [BSIP 44](https://github.com/bitshares/bsips/blob/master/bsip-0044.md). The first makes the preimage `length` parameter optional. The second adds the HASH160 algorithm to the set of allowed hash functions. And the third creates an optional `memo` field. 14 | 15 | Motivation 16 | ================= 17 | The original implementation of Hashed Timelock Contracts included a protection to prevent an attack based on the size of the preimage. While it is still believed this is a valuable feature, this makes the implementation incompatible with a strict implementation of the popular [BIP199](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki) implemented by Bitcoin. 18 | 19 | In addition, BIP199 includes the ability to use HASH160, which is not currently part of the BitShares implementation. 20 | 21 | And finally, when participating in atomic cross-chain swaps (a major benefit of HTLCs), some extra information is necessary. An optional `memo` field should be added. 22 | 23 | Risks 24 | =============== 25 | **Note** below is a discussion of HTLC risks in general, not risks inherent in implementing this BSIP. 26 | 27 | **An Oversized Preimage Attack** There are limits to the size of a preimage that can be used. That limit is set by the blockchain itself. But when dealing with atomic swaps across blockchains, an attacker could use a preimage that is too large for one side of the 2 sided transaction. That means that an HTLC can be created on both chains, but only redeemed on one chain, and not the other. 28 | 29 | This can be mitigated by specifying the preimage size as part of the contract. This feature is available on many bitcoin-based chains among others, but is not standard. Should the preimage size be used with an atomic swap, both sides of the transaction should include the preimage size in their contract. 30 | 31 | One item to keep in mind is that although a preimage size may not be explicitly specified, implicit limitations may exist. For instance, a blockchain may have limitations that make a transaction valid on one chain, but invalid on another (i.e. maximum transaction size). 32 | 33 | **Timelock Attacks** It is standard practice for HTLCs that the timelock should be long enough so that the block that contains the contract can be considered irreversible. This makes it possible for the redeemer to expose the preimage and still be guaranteed that the contract itself will not be reversed. 34 | 35 | This becomes even more important with atomic swaps. The shorter duration (a.k.a “inner”) contract should allow time to achieve its own irreversibility. And the longer duration (a.k.a. “outer”) contract must allow time for irreversibility of both. 36 | 37 | In addition, with an atomic swap both sides must consider the redemption time necessary. The creator of the inner contract must decide that should the redeemer redeem at the last moment, is there enough time to redeem the outer contract before the timelock expires. 38 | 39 | One final consideration of the timelock portion of the contract is the use of capital. Should the other party not accept, the funds in the contract are held until the timelock expires. Long expiration times could result in missed opportunity costs. 40 | 41 | Specifications 42 | ========= 43 | Technically, the implementation of these changes are small. 44 | 45 | **Preimage Size**: Permit that an HTLC can have the preimage size set to 0. This removes the size check during validation. 46 | 47 | **HASH160**: Include this additional hashing algorithm to the list of hashes available to be used. Note: A "HASH160" is simply RIPEMD160(SHA256(preimage)). 48 | 49 | **Memo**: Include this optional field for users to have an area for free-form data. It should work as does the memo field in typical BitShares transactions. This should be implemented as an extension of the `htlc_create_operation`. *Note:* adding to the htlc_object is not necessary, as existing in transaction history is sufficient. 50 | 51 | Discussion 52 | =================== 53 | While it is highly recommended that both halves of an atomic transaction provide explicit preimage lengths, the requirement as currently implemented in BitShares Core makes it incompatible with other "standardized" implementations. With the loosening of the preimage length requirement, atomic swaps that require such "standard" rules can be created on the BitShares blockchain. 54 | 55 | In addition, adding the HASH160 algorithm adds to the compatibility of BitShares Core with other blockchains. 56 | 57 | Additional discussion can be found in the issue related to this PR at https://github.com/bitshares/bsips/issues/163 58 | 59 | Copyright 60 | ==================== 61 | This document is placed in the public domain. 62 | 63 | See Also 64 | =================== 65 | [Bitshares BSIP 44](https://github.com/bitshares/bsips/blob/master/bsip-0044.md) 66 | [Bitcoin BIP 199](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki) 67 | [Preimage Size Attack](https://gist.github.com/markblundeberg/7a932c98179de2190049f5823907c016) 68 | [HTLC Operations memo](https://github.com/bitshares/bitshares-core/issues/1967) 69 | 70 | -------------------------------------------------------------------------------- /bsip-0070/flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bitshares/bsips/f8d7623fe1904eb6b1b50f4f10181c3d0ed6404d/bsip-0070/flow.png -------------------------------------------------------------------------------- /bsip-0071.md: -------------------------------------------------------------------------------- 1 | BSIP: 71 2 | Title: Add "Prevent Global Settlement" Flag for Smartcoin 3 | Authors: Jerry Liu bitcrab@qq.com 4 | Status: Draft 5 | Type: Protocol 6 | Created: 2019-07-02 7 | Discussion: https://github.com/bitshares/bsips/issues/179 8 | 9 | 10 | # Abstract 11 | 12 | This BSIP proposes a new solution to handle bad debt: the core idea is, while bad debt appears, the system does not take over the bad debt positions; instead, it accepts the smartcoin devaluation caused by bad debt and it lets borrowing, margin call, and force settlement all operate referring to the BTS/devaluated smartcoin price. This solution avoids any global/partial settlement, and keeps the borrowing, margin calls and force settlement features to continue and allow the market to decide how to finally remove bad debt, either by BTS price restoration or by debt position adjustment/ margin call order filling/force settlement. 13 | 14 | # Motivation 15 | 16 | BitShares has a mechanism to handle debt positions whose collateral is valued less than the debt itself ("bad debt"). This mechanism is called global settlement ("black swan") and is triggered when the published feed price (FP) is less than or equal to the product of the global settlement price (Pgs) and the maximum short-squeeze ratio (MSSR). 17 | 18 | FP ≤ Pgs × MSSR 19 | 20 | If this does occur it means that the collateral ratio (CR) of at least one debt position is less than the MSSR. 21 | 22 | Global settlement is not a good way to handle bad debt, as can be seen to what happened to bitUSD. After global settlement was triggered for bitUSD in December 2018: 23 | 24 | - traders could no longer borrow bitUSD; 25 | - the price of bitUSD dropped below USD because of insufficient collateral; and, 26 | - it will take a long time for bitUSD to be revived. 27 | 28 | The community has had extensive discussions about how to handle the bad debt in a better way in the future. However an easy way, [BSIP58](https://github.com/bitshares/bsips/blob/master/bsip-0058.md), has been implemented for smartcoins like bitCNY and bitUSD; it has worked successfully to prevent GS from happening with no other obvious impact. However, BSIP58 has some issues - it is suspected of market manipulation and it risks witnesses independence. Moving forward, this BSIP will be built based on BSIP58 and eliminate all its disadvantages. 29 | 30 | # Rationale 31 | 32 | We now have several choices on handling bad debt: 33 | 34 | 1. Global Settlement 35 | 2. Global Settlement Protection via Price Feeding 36 | 3. Convert Bad Debt Positions to Limit Orders 37 | 4. Take Over only Under-Collateralized Debt Positions without GS (aka Partial GS) 38 | 5. Prevent Global Settlement 39 | 40 | We need to do a deep review on bad debt before evaluating above solutions. 41 | 42 | Bad debt means in some debt positions the debt cannot be fully paid by selling the collaterals via margin call/force settlement at the market price. In other words, the relevant smartcoin loses sufficient collateral to back the value and will possibly devalue. 43 | 44 | At this moment, the system should accept the fact that the smartcoin will possibly devalue, find ways to minimize the impact to different parties in the market and the time to revive. 45 | 46 | In my view, a good way to handle bad debt need to follow below principles: 47 | 48 | 1. Do not punish good traders who have managed to maintain their collateral ratio well. 49 | 2. Do not stop the smartcoin features, including borrowing, margin call and force settlement. 50 | 3. Ensure the debt positions/margin call orders be settled in the order from lower CR to higher CR. 51 | 52 | In above mentioned 5 solutions, only "5. Prevent Global Settlement" fulfills all 3 principles. 53 | 54 | Partial GS is another attractive solution: it is similar to Global Settlement but differs in that (a) only takes over the bad debt positions and moves them to a settlement pool without touching the debt positions with CR>1, and (b) users can issue force settlement from the pool, from the margin call orders, or from the good debt position depending on which has the lowest CR. 55 | 56 | The problem of Partial GS is that it does not resolve itself automatically when the price recovers. 57 | 58 | The "Prevent Global Settlement" solution adopts a new idea to handle bad debt: while bad debt appears, the smartcoin will be devaluated at a ratio of the lowest CR from among the bad debt positions, yet all the smartcoin trading features, including borrowing, margin call and force settlement, will all switch to refer to GS price to ensure the continuity and fairness of all the features. 59 | 60 | # Specifications 61 | 62 | Add one flag "Prevent Global Settlement" to each smartcoin asset. 63 | 64 | Introduce new parameters: *settlement price* and *call execution price*. They shall be calculated as: 65 | 66 | ``` 67 | if flag "Prevent Global Settlement" is enabled 68 | settlement price = max(FP_M * (1 - settlement_offset), P_gs) 69 | call execution price = max(FP_M * (1 + MSSR), P_gs) 70 | else 71 | settlement price = FP_M * (1 - settlement_offset) 72 | call execution price = FP_M * (1 + MSSR) 73 | ``` 74 | 75 | where *FPM* is the median of the prices published by witnesses, *MSSR* is the [maximum short-squeeze ratio](https://github.com/bitshares/bitshares-core/blob/e8567d0425ec27d29036a9a9178df5afd8ca6f25/libraries/protocol/include/graphene/protocol/asset.hpp#L192-L193) and *settlement offset* is the [force settlement offset](https://github.com/bitshares/bitshares-core/blob/e8567d0425ec27d29036a9a9178df5afd8ca6f25/libraries/protocol/include/graphene/protocol/asset_ops.hpp#L105-L106); witnesses should always feed the real market price. 76 | 77 | The *settlement price* is the price that is used when executing forced settlements. Note that when a large forced settlement fills up a debt position completely, Pgs is likely to change. The resulting new *settlement price* will be used when settling against the next debt position. 78 | The *call execution price* is the price that is used when matching margin calls against limit orders or settlement requests. Again, when a large match fills up a debt position completely, Pgs is likely to change. The resulting new *call execution price* will be used when settling against the next debt position. 79 | FPM is still used for determining if a debt position is margin called, as before, at FPM × (1 + [MCR](https://github.com/bitshares/bitshares-core/blob/e8567d0425ec27d29036a9a9178df5afd8ca6f25/libraries/protocol/include/graphene/protocol/asset.hpp#L189-L190)). 80 | 81 | **Note:** when comparing prices, `max` is to be understood in terms of debt %div; collateral. 82 | 83 | # References 84 | 85 | - [New mechanism to handle bad debt (black swan)](https://bitsharestalk.org/index.php?topic=27273.0) 86 | - [New BSIP：GS protection via core code](https://bitsharestalk.org/index.php?topic=28681.0) 87 | - [New BSIP: Add "Prevent Global Settlement" Flag for Smartcoin (old title: Global Settlement Protection via core code)](#179) 88 | - [New BSIP: Add "Prevent Global Settlement" Flag for Smartcoin](#193) 89 | 90 | # Discussion 91 | 92 | ## settlement_price / feed_price 93 | 94 | Some may perceive it as confusing or unfair that borrowing and force settlement may refer to different prices. However, in a period where the least collateralized short position has insufficient collateral in terms of FP_m, it would be dangerous to use the resulting settlement_price for borrowing as well, because that would allow creation of short positions that are undercollateralized from the start. 95 | 96 | ## Least collateralized short 97 | 98 | Two variants for the *call execution price* have been discussed. 99 | 100 | Variant A (as specified here) prefers to match the bad debt positions first, hoping that this way the bad debt will be resolved quickly. This also means that if Pgs moves away from the market price, **no** margin calls will be filled, not even those with a collateral ratio that would allow them being matched with market orders. This can lead to more bad debt piling up instead of resolving at least some debt positions through margin calls. 101 | 102 | Variant B would have let bad debt positions matched at their own collateral ratio while matching other margin calls as before at FPM × MSSR, hoping to improve the overall collateralization. This also means that debt positions with better collateral ratio would have been preferred over bad debt, meaning that bad debt positions will remain sitting on the market for a longer time. 103 | 104 | # Summary for Shareholders 105 | 106 | It is important to eliminate concerns about global settlement. This is currently achieved with the technical options that are available to the witnesses. A more advanced solution as proposed here is needed. 107 | 108 | # Copyright 109 | 110 | This document is placed in the public domain. 111 | -------------------------------------------------------------------------------- /bsip-0074.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BSIP: 0074 3 | Title: Margin Call Fee Ratio 4 | Authors: 5 | Jerry Liu bitcrab@qq.com 6 | Christopher Sanborn christopher.sanborn@bitshares.org 7 | Status: Installed 8 | Type: Protocol 9 | Created: 2019-09-07 10 | Discussion: https://github.com/bitshares/bsips/issues/164 11 | Worker: TBD 12 | ``` 13 | 14 | # Abstract 15 | This BSIP provides a solution to charge a fee from margin call trading. 16 | 17 | # Motivation 18 | Bitshares community becomes more and more aware that BTS need a powerful economy model, one simple selection is to charge the tradings and buy back BTS using the accumulated fees, as did in many exchange platform tokens, the continuous income can help to provide smartcoin liquidity and sustain BTS price. Margin call tradings are potential to contribute a big part of the income to the system, however up to now the margin call trading is not charged, we need to find a suitable way to get this part of system income. 19 | 20 | # Rationale 21 | Margin call fee can be seen as to pay the cost for smartcoin supply and stabilization, it is unrelated to market fee sharing. 22 | 23 | To ensure the debt positions can always be closed with sufficient smartcoin, it is more feasible to cut off part of the traded collaterals as fee, instead of smartcoin. 24 | 25 | As the margin call fee ratio may be obvious higher than market fee, the margin call orders should be placed at the real price without margin call fee to avoid misleading the buyer. 26 | 27 | # Specification 28 | 29 | ### Fee Parameter and Margin Call Order Price 30 | 31 | Add one new parameter, Margin Call Fee Ratio (MCFR), for each smartcoin, which is controlled by the smartcoin owner. This fee ratio will modulate the Maximum Short Squeeze Ratio (MSSR) when determining the Margin Call Order Price (MCOP): 32 | 33 | `margin_call_order_price = median_feed_price / (MSSR - MCFR)`. 34 | 35 | Here, `margin_call_order_price` is the price at which margin calls will enter the market order book, and `median_feed_price`(1) conveys the "even exchange" price between DEBT and COLLATERAL, as reported by the price feed publishers. Both prices are expressed in units of DEBT / COLLATERAL. 36 | 37 | This new calculation of MCOP differs from previous behavior. Previously, margin calls entered the book at the Maximum Short Squeeze Price (MSSP), defined as: 38 | 39 | `max_short_squeeze_price = median_feed_price / MSSR`. 40 | 41 | The MSSP is retained under this BSIP as the collateralization threshold at which global settlement can be triggered, but it no longer determines the order price. 42 | 43 | _**Note (1):** In the core source code, as of this writing, what we here call `median_feed_price` is called `settlement_price`, although it represents the median reported price feed. Even though it would match current code, we have preferred not to use the symbol `settlement_price` as a synonym for median feed price in this document for two reasons: (1) the value is not identical with the price at which force settlements occur, due to the Force Settlement Offset (FSO), thus the symbol is confusing, and (2) [BSIP-0071](bsip-0071.md) uses the symbol `settlement_price` to refer to the price at which force settlements occur, inclusive of the FSO, and we do not wish to add ambiguity by using a different definition here._ 44 | 45 | ### Fee Calculation 46 | 47 | #### Review of order-matching sequence: 48 | 49 | A margin call will enter the book at the MCOP. However, if at the time the call enters the book, (or any time thereafter in response to a price feed update), it can be matched with an existing limit order at a more favorable price, it will take that order. This means that the `match_price` will be some price no worse than (from the perspective of the callee) the MCOP: 50 | 51 | `match_price >= margin_call_order_price`. _(when margin call is a taker)_ 52 | 53 | If no immediate match is found, then the call order will wait on the books (as a maker) for a future limit order to take it. In this case, the eventual match price is exactly the order price: 54 | 55 | `match_price = margin_call_order_price`. _(when margin call is a maker)_ 56 | 57 | #### Calculation of fee, general case: 58 | 59 | When a call order is matched to a limit order and they exchange _X_ amount of smartcoin, this BSIP proposes that two distinct quantities be calculated: the amount of collateral which the limit order receives from the call order in exchange for _X_, and the total amount of collateral that the call order relinquishes to satisfy obligations including the margin call fee. If the MCFR parameter is zero, then these two quantities are equal, and the behavior is unchanged from before. But if the MCFR is non-zero, then the relinquished collateral will be a greater quantity than what is payed to the limit order. The excess is to be paid to the smartcoin asset owner as the _Margin Call Fee_. 60 | 61 |
62 | 63 | `limit_order_receives = X / match_price` 64 | 65 | `call_order_relinquishes = (X / match_price) * [MSSR / (MSSR - MCFR)]` 66 | 67 | `margin_call_fee = call_order_relinquishes - limit_order_receives`. 68 | 69 |
70 | 71 | This calculation results in a Margin Call Fee which is proportional to the amount of collateral paid to the limit order to buy _X_ amount of smartcoin. 72 | 73 | #### Calculation of fee, maker case: 74 | 75 | Note that in the case when the margin call enters the book as a maker order (i.e., when it was not able to immediately find an existing favorable limit order), the match price will be identical to the order price, which allows the forgoing calculations to simplify as follows: 76 | 77 |
78 | 79 | `limit_order_receives = X * (MSSR - MCFR) / median_feed_price` 80 | 81 | `call_order_relinquishes = X * MSSR / median_feed_price = X / max_short_squeeze_price` 82 | 83 | `margin_call_fee = X * MCFR / median_feed_price` 84 | 85 |
86 | 87 | The above simplification offers two insights into the Margin Call Fee: 88 | 89 | 1. The reason why Maximum Short Squeeze Price is retained as the Global Settlement threshold is because this is the price that determines the total amount of collateral a call order must relinquish under least favorable conditions, and, 90 | 91 | 2. That the MCFR can be interpreted as defining a fraction of the feed price that establishes the maximum fee rate paid by the callee. (I.e., the fee will not exceed `MCFR * X / median_feed_price`.) 92 | 93 | 94 | ### Fee Floor 95 | 96 | Because the effect of the Margin Call Fee is to reduce the amount of collateral offered by the margin call to buy back debt, there is a danger that the margin call could offer less collateral than the "even exchange" value of the debt (as reported by the price feed publishers), making it unlikely to match the call with a buyer. To prevent this, the implementation should include a floor wherein every place that `MSSR - MCFR` appears, it is replaced with: 97 | 98 | `(MSSR - MCFR)` —> `max((MSSR - MCFR), 1.000)`. 99 | 100 | This will ensure that the amount of collateral offered by the margin call is never valued less than the quantity of debt which the call seeks to buy. At the same time, however, it may mean that the asset owner receives less collateral (or even no collateral) than they are expecting in fees. Asset owners should be advised not to expect to collect a fee rate greater than (MSSR - 1.000). 101 | 102 | # Non-technical Summary 103 | 104 | In summary, this BSIP proposes that the Maximum Short Squeeze Price, which previously established both the price at which margin calls offered collateral _and_ the collateralization threshold at which Global Settlement occurs, be separated into two distinct concepts: 105 | 106 | 1. **Margin Call Offer Price** — The price at which margin calls offer to sell collateral in order to buy debt, and, 107 | 108 | 2. **Maximum Short Squeeze Price** — The most extreme price at which a call order will be required to relinquish collateral in order to satisfy the combined obligation of buying debt and paying the margin call fee. Because the margin call must hold at least this much collateral (per unit debt) in order to relinquish it, this also becomes the collateralization threshold at which Global Settlement can be triggered. 109 | 110 | # Copyright 111 | 112 | This document is placed in the public domain. 113 | -------------------------------------------------------------------------------- /bsip-0075.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BSIP: 0075 3 | Title: Asset Owner Defines MCR and MSSR Values 4 | Authors: 5 | Bangzi1001 6 | John Jones 7 | Michel Santos 8 | Status: Installed 9 | Type: Protocol 10 | Created: 2019-09-19 11 | Discussion: https://github.com/bitshares/bsips/issues/96 12 | Worker: TBD 13 | ``` 14 | 15 | # Abstract 16 | This BSIP provides the ability for the asset creator to decide if adjustments to the Maintenance Collateral Ratio (MCR) or the Maximum Short Squeeze Ratio (MSSR) should be done by the asset owner or by price feed providers. 17 | 18 | # Motivation 19 | Asset owners are often in the best position to control the values of MCR and MSSR of their asset. Therefore, they should be able to have direct control to adjust those values, should they choose to allow themselves. They should also be able to forfeit this direct control. 20 | 21 | # Rationale 22 | Prior to this change, adjustments to MCR and MSSR were handled by feed producers. This often requires the asset owner to contact the feed producer and ask for the change. For some assets, such a step is time consuming for both parties and ill-fitted as part of the feed producer's responsibilities. 23 | 24 | This new change shall permit the asset owner to determine who should have the responsibility to maintain those values. It shall also permit the asset owner to forfeit the right to update the parameter. Therefore the asset owner may continue changing the responsibility unless and until the permission is forfeited. 25 | 26 | 27 | # Specification 28 | 29 | **Note:** "Implementation Hints" are not to be considered part of the formal specification, but merely as a _possible_ implementation. 30 | 31 | ## Parameter 32 | 33 | Each of these new issuer-defined parameters shall be independently configurable of the other. 34 | 35 | **Implementation Hint:** New optional fields in `bitasset_options` may be defined for every asset to contain these new parameters 36 | 37 | ``` 38 | struct bitasset_options 39 | { 40 | struct ext { 41 | //... 42 | /// The parameters which the issuer has permission to update 43 | optional mcr; // Maintenance Collateral Ratio 44 | optional mssr; // Maximum Short Squeeze Ratio 45 | } 46 | }; 47 | ``` 48 | 49 | ## Effect of a Parameter 50 | 51 | All relevant blockchain contracts _shall use_ a parameter _if it is set_ and _shall ignore_ the derived parameters from the asset's published feeds. 52 | 53 | All relevant blockchain contracts _shall ignore_ a parameter _if it is not set_ and _shall use_ the derived parameters from the asset's published feeds. 54 | 55 | At the time that this BSIP activates, these issuer-defined parameters shall not be _set_ and will therefore not affect the current behavior of the asset _unless and until_ each asset owner sets a parameter. 56 | 57 | An asset owner shall also be able to set and unset a parameter at will unless the permission to change that parameter has been forfeited as described in [Permission to Change the Parameter](#permissions). 58 | 59 | 60 | ##
Permission to Change the Parameters
61 | 62 | The permission to change any of these parameters shall make use of new permissions. _Each of the parameters shall have its own distinct permission._ Disabling the permission prohibits the changing of the parameter as described in [Changing the Parameters](#changing-parameters). 63 | 64 | The existing set of asset issuer permissions shall be expanded to permit an asset owner to forfeit changing the parameters. It shall not be permitted to regain a permission after it is forfeited unless the supply of the asset is zero. 65 | 66 | Existing software clients might not be updated to make use of these new parameters. Changing the permissions shall be designed such that older software clients may not accidentally forfeit these permissions either for existing assets or new assets. _The parameters and the permissions to change parameters shall be designed such that they are defaulted to enabled. The permissions shall be designed such that **explicit disabling/forfeiting** is required which should not be possible with older software clients._ 67 | 68 | **Implementation Hints** 69 | 70 | The `asset_object.asset_options.issuer_permissions` may be expanded to include `disable_mcr_update`, `disable_mssr_update`. 71 | 72 | Appropriate changes to the ASSET_ISSUER_PERMISSION_MASK and UIA_ASSET_ISSUER_PERMISSION_MASK are advised to be both backward and forward compatible. 73 | 74 | 75 | ##
Changing the Parameters
76 | 77 | It shall be possible to set and unset a parameter at any time __if and only if__ its respective [permission](#permissions) is enabled. 78 | 79 | **Implementation Hints** 80 | 81 | The `create_asset_operation` can be modified to include the setting of the parameters above. 82 | 83 | The `update_asset_operation` can be modified to disable/forfeit the permissions to change, and to enable/regain the permissions _if_ the supply is zero. 84 | 85 | The `asset_update_bitasset_operation` can be modified to permit updating of the MCR and MSSR values, if the asset has the appropriate permissions. Much of the logic currently in `asset_publish_feeds_evaluator::do_apply()` (i.e. call order checks and calculations) can be called here if MCR and MSSR are adjusted. 86 | 87 | Note: older client software may unexpectedly unset a parameter (although not a flag nor a permission) that is already set due to incompatibility. When a new parameters was sucessfully set or updated, the asset owner was aware of the new feature and has been using client software that is compatible to the new feature, the asset owner should already be aware of the risks of using incompatible older client software and should avoid using it when possible. 88 | 89 | # Discussion 90 | 91 | Any client software that intends to allow owners of smart assets to create or to change these new parameters will need to be updated. Older client software may continue to be used but will not be able to view, change, or set these new parameters. 92 | 93 | 94 | ## Risks 95 | 96 | If an asset owner **sets** a parameter and later forfeits the permission to change the parameter, **that parameter will be locked forever**. In contrast, if an asset owner leaves a parameter **unset** and later forfeits the permission to change the parameter, that parameter can still be changed by current and future feed publishers. 97 | 98 | If an asset owner has set a parameter with compatible (new) client software, but uses incompatible (old) client software afterwards, the parameter may be unset unexpectedly by the incompatible client software. 99 | 100 | # Summary for Shareholders 101 | For some assets, having feed producers control MCR and MSSR values is cumbersome and ill-fitting. This BSIP allows asset owners to decide at asset creation time if the responsibility of those values should be from feed producers' consensus or set directly by the asset owner themselves. 102 | 103 | # Copyright 104 | This document is placed in the public domain. 105 | 106 | # See Also 107 | [BSIP 59](https://github.com/bitshares/bsips/blob/master/bsip-0059.md) documents procedures for adjusting MCR and MSSR of smartcoins by polling. 108 | -------------------------------------------------------------------------------- /bsip-0076.md: -------------------------------------------------------------------------------- 1 | BSIP: 0076 2 | Title: Threshold for price feeds through voting 3 | Authors: Abit More 4 | Status: Draft 5 | Type: Informational 6 | Created: 2019-09-25 7 | 8 | # Abstract 9 | 10 | This BSIP defines a process to influence the pegging status of committee-owned smartcoins through poll voting. 11 | 12 | # Motivation 13 | 14 | In order to maintain the peg of the smartcoins, smartcoins holders now have the right to be always 15 | possible to buy collateral at a "fair" price. For committee-owned smartcoins, the collateral is BTS. 16 | However, when the BTS token is being dumped in Centralized Exchanges with fake volume and even fake supply, 17 | the value of the token is distorted, thus, forcing BTS token holders who have their BTS token trapped in 18 | debt positions as collateral to sell their collateral at the distorted price via margin calls or 19 | force-settlements is unfair. 20 | The same situation applies to non-committee-owned smart coins as well. 21 | 22 | Smartcoins are products of the BitShares platform, their rules are defined by the platform 23 | for the benefit of the platform and the BTS token holders. 24 | If a product brings more harm than benefit to the platform, its rules need to be optimized, 25 | under extreme conditions, the product needs to be halted. 26 | For smartcoins, when the cost to maintain the peg is too high to afford, it's time to give up the peg. 27 | 28 | # Rationale 29 | 30 | Ideally a smartcoin owner should be able to define a set of conditions about when to give up the peg 31 | and how to de-peg, but it needs time to design and implement. Before the final solution got worked out, 32 | it's up to the price feed producers to execute the will for the asset owner on whether to maintain 33 | the peg at a given point and how to de-peg. For committee-owned smartcoins, the owner is actually 34 | all BTS holders who could express their will by voting, the price feed producers are the active witnesses. 35 | 36 | # Specification 37 | 38 | The BTS token holders define a threshold, if the market trading price of BTS is below the threshold, 39 | witnesses should feed the threshold but not the market trading price, thus would effectively break 40 | the peg as intended. When the market trading price of BTS is above the threshold, witnesses should 41 | feed the market trading price, so the peg will be restored automatically. The mechanism is similar to 42 | the Global-Settlement Protection mechanism as described in [BSIP 58](bsip-0058.md). 43 | 44 | Changes to the threshold will be decided on individual committee-owned smartcoins by voting, each time 45 | one change is issued 2 poll worker proposals will be created standing FOR and AGAINST the change. 46 | 47 | For example, to decide whether to change the price feed threshold of bitCNY to 0.2 CNY each BTS, 48 | 2 poll worker proposals will be created for voting: 49 | 50 | Poll-BSIP**-Change bitCNY feed threshold [from the previous value when applicable] to 0.2 CNY per BTS 51 | 52 | Poll-BSIP**-Not change bitCNY feed threshold [from the previous value when applicable] to 0.2 CNY per BTS 53 | 54 | If the voting confirm the change, committee will announce the change at least 3 days before the change 55 | is implemented by witnesses. 56 | 57 | # Discussion 58 | 59 | Some people think it's the debt position holders' responsibility to always maintain their 60 | collateral ratio to a fair level. However, when the collateral's price can drop to zero due to 61 | unfair manipulation, it's not possible to always maintain a good CR. 62 | Higher or lower, there is a point that the peg would break. 63 | 64 | This BSIP may negatively impact smartcoin holders since their holdings will likely devalue when 65 | the voted point is met, which would likely be worse than before. 66 | Businesses built on top of the smartcoins may be impacted. 67 | Reputation of smartcoins as well as the BitShares brand may be impacted. 68 | 69 | Discussions about changing the threshold to what value is not in the scope of this BSIP. 70 | The values should be carefully selected to comply with the market status and to mitigate potential risks. 71 | Voters will need to evaluate each setting that is proposed in a BSIP poll. 72 | 73 | A new feature that allows an asset owner to directly set, update or unset the threshold will 74 | be described in a new BSIP. It's not in the scope of this BSIP. 75 | 76 | # Non-Technical Summary 77 | 78 | It is important to define a process for the BTS token holders to decide to change 79 | pegging status of committee-owned smartcoins through voting. 80 | This can currently be achieved with the technical options that are available to 81 | the price feed producers aka witnesses. 82 | 83 | # See Also 84 | * https://bitsharestalk.org/index.php?topic=29635.0 85 | * https://bitsharestalk.org/index.php?topic=29633.0 86 | 87 | # Copyright 88 | This document is placed in the public domain. 89 | -------------------------------------------------------------------------------- /bsip-0077.md: -------------------------------------------------------------------------------- 1 | BSIP: 0077 2 | Title: Require Higher CR When Creating / Adjusting Debt Positions 3 | Authors: Abit More 4 | @shulthz 5 | Michel Santos 6 | Status: Installed 7 | Type: Protocol 8 | Created: 2019-09-30 9 | 10 | # Abstract 11 | 12 | This BSIP proposes a protocol change which aims to improve overall collaretal ratio (CR) of smartcoins. 13 | 14 | # Motivation 15 | 16 | Risk-loving traders tend to borrow as much debt as possible with as little collateral as possible, 17 | which impacts overall CR of that smartcoin. Smartcoin owners would like to have a tool to counter 18 | this behavior. 19 | 20 | # Rationale 21 | 22 | Requiring a higher CR for new debt positions would introduce a buffer thus would increase the 23 | stability of the smartcoin. 24 | 25 | # Specification 26 | 27 | **Note:** "Implementation Hints" are not to be considered part of the formal specification, but merely as a _possible_ implementation. 28 | 29 | ## Parameter 30 | 31 | Add one "Initial Collateral Ratio" (ICR) parameter to each smartcoin asset, which can be updated by the asset owner. 32 | 33 | Add one "Initial Collateral Ratio" (ICR) parameter to each smartcoin's price feed, which can be updated by the asset's feed publishers. 34 | 35 | **Implementation Hint:** The optional field that can be set by the asset owner could be placed in `bitasset_options`. 36 | 37 | ``` 38 | struct bitasset_options 39 | { 40 | struct ext { 41 | //... 42 | /// The ICR parameter which the asset owner/"issuer" has permission to update 43 | optional initial_collateral_ratio; 44 | } 45 | }; 46 | ``` 47 | 48 | **Implementation Hint:** The optional field that can be set by the feed publishers of an asset could be placed in `asset_publish_feed_operation`. 49 | 50 | ``` 51 | struct asset_publish_feed_operation 52 | { 53 | struct ext { 54 | //... 55 | /// The ICR parameters which the feed publisher has permission to update 56 | optional initial_collateral_ratio; 57 | } 58 | }; 59 | ``` 60 | 61 | 62 | ## Effect of a Parameter 63 | 64 | The inital collateral ratio (ICR) shall equal the asset owner's ICR parameter _if it is explicitly set._ _Otherwise_ it shall equal the median value of the feed publisher's ICR parameter. Any individual feed publisher's ICR shall default to the maintenance collateral ratio (MCR) if the feed publisher's ICR _is not explicitly set_. 65 | 66 | When adjusting a position, **the logic of [BSIP30](https://github.com/bitshares/bsips/blob/master/bsip-0030.md) shall be amended** such that the current CR shall be compared to the ICR **instead of** the maintenance collateral ratio (MCR). The effects of this BSIP's amendment on the relevant smart contracts can be summarized in a comparison of the desired behaviors _before versus after_ the protocol upgrade. 67 | 68 | **Before the protocol upgrade:** 69 | ``` 70 | When creating a new debt position 71 | Require CR > MCR 72 | 73 | When adjusting a debt position 74 | If new CR <= MCR 75 | Require CR increased and debt not increased 76 | 77 | When current CR <= MCR 78 | Trigger margin call 79 | ``` 80 | 81 | **After the protocol upgrade:** 82 | ``` 83 | Require ICR >= MCR 84 | 85 | When creating a new debt position 86 | Require CR > ICR 87 | 88 | When adjusting a debt position 89 | If new CR <= ICR 90 | Require CR increased and debt not increased 91 | 92 | When current CR <= MCR 93 | Trigger margin call 94 | ``` 95 | 96 | _Note: The logic around *target collateral ratio* (TCR) is not affected._ 97 | 98 | At the time that this BSIP activates, the new Initial Collateral Ratio parameter will not be _set_ and _shall therefore default to the current MCR value_. Similarly, whenever the Initial Collateral Ratio is unset by an asset owner, the ICR value _shall default to the current MCR value_. 99 | 100 | An asset owner shall be able to set and unset a parameter at will unless the permission to change that parameter has been forfeited as described in [Permission to Change the Parameter](#permissions). 101 | 102 | 103 | ##
Permission to Change the Parameters
104 | 105 | The permission to change the _asset owner's_ parameter shall make use of a new permission. Disabling the permission prohibits the changing of the parameter as described in [Changing the Parameter](#changing-parameters). 106 | 107 | The existing set of asset owner permissions shall be expanded to permit an asset owner to forfeit the permission to change the new parameter. The asset owner shall not be permitted to regain a permission after it is forfeited unless the supply of the asset is zero. 108 | 109 | Existing software clients might not be updated to make use of the new parameter. Changing the permissions shall be designed such that older software clients may not accidentally forfeit the permission either for existing assets or new assets. _The parameter and the permission to change parameter shall be designed such that they are defaulted to enabled. The permission shall be designed such that **explicit disabling/forfeiting** is required which should not be possible with older software clients._ 110 | 111 | **Implementation Hints** 112 | 113 | The `asset_object.asset_options.issuer_permissions` could be expanded to include `disable_icr_update`. 114 | 115 | Appropriate changes to the ASSET_ISSUER_PERMISSION_MASK and UIA_ASSET_ISSUER_PERMISSION_MASK are advised to be both backward and forward compatible. 116 | 117 | 118 | ##
Changing the Parameter
119 | 120 | It shall be possible to set and unset the _asset owner's_ parameter at any time __if and only if__ its respective [permission](#permissions) is enabled. 121 | 122 | **Implementation Hints** 123 | 124 | The `create_asset_operation` could be modified to include the setting of the parameters above. 125 | 126 | The `update_asset_operation` could be modified to disable/forfeit the permissions to change, and to enable/regain the permissions _if_ the supply is zero. 127 | 128 | The `asset_update_bitasset_operation` could be modified to permit updating of the ICR value, if the asset has the appropriate permissions. 129 | 130 | 131 | # Discussion 132 | 133 | Any client software that intends to allow owners of smart assets to create or to change the new parameters will need to be updated. Older client software may continue to be used but will not be able to view, change, or set the new parameter. 134 | 135 | ## Risks 136 | 137 | **Older** client software may unexpectedly unset a parameter (although not a flag nor a permission) that is already set due to incompatibility. When a **new** parameter is sucessfully set or updated, the asset owner **demonstrates awareness of the new feature** by using client software that is compatible with the new feature. **The asset owner should be aware of the risks of using incompatible older client software and should avoid using it when possible.** 138 | 139 | If an asset owner **sets** a parameter and later forfeits the permission to change the parameter, **that parameter will be locked forever**. 140 | 141 | If an asset owner has set a parameter with compatible (new) client software, but uses incompatible (old) client software _afterwards_, the parameter may be unset unexpectedly by the incompatible client software. 142 | 143 | 144 | # Summary for Shareholders 145 | 146 | This BSIP introduces a new tool for smartcoin asset owners to fine tune their assets. 147 | Having an ICR greater than MCR would probably result in less risk-loving traders borrowing that 148 | smartcoin, thus may lead to fewer market activities and worse liquidity. It is up to the asset 149 | owners to decide whether to use this tool. 150 | 151 | # References 152 | * https://github.com/bitshares/bsips/issues/129#issuecomment-483937118 153 | * https://github.com/bitshares/bsips/issues/96#issuecomment-484126930 154 | * https://bitsharestalk.org/index.php?topic=29638.0 155 | 156 | # Copyright 157 | This document is placed in the public domain. 158 | -------------------------------------------------------------------------------- /bsip-0081.md: -------------------------------------------------------------------------------- 1 | BSIP: 0081 2 | Title: Simple Maker-Taker Market Fees 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2019-10-02 7 | Discussion: https://github.com/bitshares/bsips/issues/229 8 | Obsoletes: BSIP-0003 9 | Worker: TBD 10 | 11 | # Abstract 12 | [BSIP67](https://github.com/bitshares/bsips/issues/130) proposed a mechanism 13 | which has maker-taker fees in consideration, but it's relatively complex. 14 | 15 | This BSIP proposes a protocol change to enable asset owners to specify 16 | different market fee rate for maker orders and taker orders. 17 | 18 | # Motivation 19 | 20 | Asset owners need tools to incentivize trading of their assets. 21 | 22 | # Rationale 23 | 24 | Maker-taker fee model is adopted widely in centralized exchanges and helped 25 | them to attract trading activities. 26 | 27 | # Specification 28 | 29 | There is already a flag `market_fee_percent` in asset options. 30 | 31 | Add a new optional flag `taker_fee_percent` into asset options, 32 | which can only be set 33 | or updated by asset owners after the consensus upgrade. 34 | The valid range of the new flag is `[0%, 100%]`. 35 | 36 | Before the consensus upgrade, when an order buying that asset 37 | got filled, the amount `bought_amount * market_fee_percent` 38 | (capped by `max_market_fee`) 39 | will enter the asset's market fee sharing process. 40 | 41 | After the consensus upgrade, when an order buying the asset 42 | got filled, 43 | * if the order is a *maker*, or the `taker_fee_percent` flag 44 | is not set in the asset, the amount 45 | `bought_amount * market_fee_percent` 46 | (capped by `max_market_fee`) 47 | will enter the asset's market fee sharing process; 48 | * otherwise (if the order is a *taker* and the 49 | `taker_fee_percent` is set in the asset), the amount 50 | `bought_amount * taker_fee_percent` 51 | (capped by `max_market_fee`) 52 | will enter the asset's market fee sharing process. 53 | 54 | # Copyright 55 | This document is placed in the public domain. 56 | -------------------------------------------------------------------------------- /bsip-0085.md: -------------------------------------------------------------------------------- 1 | BSIP: 0085 2 | Title: Maker order creation fee discount 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2019-10-13 7 | Discussion: https://github.com/bitshares/bsips/issues/240 8 | Worker: TBD 9 | 10 | # Abstract 11 | 12 | This BSIP proposes a protocol change so that the committee can define 13 | different transaction fee rates for maker orders and taker orders. 14 | 15 | # Motivation 16 | 17 | To improve liquidity of the BitShares DEX by creating the ability to incentivize market making. 18 | 19 | # Rationale 20 | 21 | The maker-taker fee model is adopted widely in centralized exchanges and 22 | helped them to attract trading activities. 23 | 24 | In the BitShares DEX, for each filled order, the owner of the order need to 25 | pay an order creation fee and conditionally a market fee. 26 | [BSIP 81](bsip-0081.md) described 27 | a way to apply the maker-taker fee model to the market fee. This BSIP 28 | describes a way to apply the maker-taker fee model to the order creation fee. 29 | 30 | # Specification 31 | 32 | Add a new global parameter `maker_fee_discount_percent` which can 33 | be updated by the committee only after the protocol upgrade. 34 | Initial value of that parameter is `0`. 35 | Valid range of that parameter is `[0, 100%]`. 36 | 37 | When a limit order is filled or partially filled for the first time, 38 | technically, when its `deferred_fee` field is non-zero, 39 | * if the order is a take order, process the deferred fee as before; 40 | * if the order is a maker order, 41 | * if the order creation fee was paid in BTS, return 42 | `round_down(deferred_fee * maker_fee_discount_percent)` to the owner, 43 | then process the remaining deferred fee as before; 44 | * if the order creation fee was paid in another asset, return 45 | `round_down(deferred_paid_fee * maker_fee_discount_percent)` 46 | to the owner, return 47 | `round_down(deferred_fee * maker_fee_discount_percent)` to 48 | the fee pool of the asset, then process the remaining deferred fee 49 | and deferred paid fee as before. 50 | 51 | # Discussion 52 | 53 | As of writing, to incentivize market making, the `limit_order_create` 54 | operation fee is very small. However, since there is only one fee, 55 | the fee for consuming liqudity is also very small. 56 | This BSIP gives the committee a tool to increase fee for consuming 57 | liquidity while still keeping a low cost for market makers to provide 58 | liquidity. 59 | 60 | # Copyright 61 | This document is placed in the public domain. 62 | -------------------------------------------------------------------------------- /bsip-0086.md: -------------------------------------------------------------------------------- 1 | BSIP: 0086 2 | Title: Share market fees to the network 3 | Author: Abit More 4 | Status: Installed 5 | Type: Protocol 6 | Created: 2019-11-29 7 | Discussion: https://github.com/bitshares/bsips/issues/194 8 | Worker: 1.14.245 9 | 10 | # Abstract 11 | 12 | This BSIP proposes a protocol change: Every time a trade is executed (limit order is filled) and 13 | if there are market fees generated, a portion of the market fees goes to the network. 14 | 15 | Example: The network percent of market fees is set to 50%, and 0.2% of trading volume is the set as market fee. 16 | Then 0.1% of trading volume goes to the network. 17 | 18 | # Motivation 19 | 20 | The network needs more tools to generate income to support its development. 21 | 22 | # Rationale 23 | 24 | A major activity in the network is trading assets. The asset owners make 25 | profits in the form of market trading fees. Currently, the main tools for the 26 | network to generate income from asset trading activities are order creation 27 | fee and order cancellation fee. It seems reasonable that the asset owners 28 | share some profits (a part of market fees) to the network to support its 29 | development. 30 | 31 | The cut of market fees can go to committee-account's vesting balances. 32 | As a supporting measure, committee-account should be exempted from 33 | white-listing restrictions, so that it is able to claim the vesting balances 34 | and sell them for core token or other tokens to pay for development later. 35 | 36 | # Specifications 37 | 38 | ## Protocol upgrade 39 | 40 | A time will need to be scheduled for applying the change. In this document, 41 | terms "before the protocol upgrade", "at the protocol upgrade" and "after 42 | the protocol upgrade" may or may not be used to indicate things happen before 43 | the scheduled time, at the scheduled time and after the scheduled time. 44 | 45 | ## New global parameter 46 | 47 | Add a new global parameter `market_fee_network_percent` which can be updated 48 | by the committee only after the protocol upgrade. 49 | Initial value of that parameter is `0%`. 50 | Valid range of that parameter is `[0%, 30%]`. 51 | 52 | ## When processing market fees 53 | 54 | After the protocol upgrade, when splitting a non-zero market fee, firstly 55 | split `amount * market_fee_network_percent` (round down) to committee-account, 56 | then process the remainder as before. The amount split to committee-account 57 | should go to the vesting balance object whose type is `market_fee_sharing`. 58 | 59 | ## When checking asset authorities 60 | 61 | After the protocol upgrade, when checking authorities (E.G. white-lists) of an 62 | asset on an account, if the account is committee-account, let it pass. 63 | 64 | # Discussion 65 | 66 | * Other than [the "coin-days as market fees" proposal]( 67 | https://github.com/bitshares/bsips/issues/191) which applies 68 | a discount to market fees to benefit core token holders directly, this BSIP 69 | seeks for a mechanism to increase the network's income and benefit core token 70 | holders indirectly. 71 | 72 | * Adjusting the fee schedule and network percent in the referral program is 73 | another option to increase the network's income, and is probably sufficient 74 | for funding development. 75 | 76 | * In the original design, the purpose of market fees is to reward asset 77 | issuers for their work (e.g. gateway providers, or businesses built around 78 | PMs), while operation fees (`limit_order_create/cancel` in particular) reward 79 | the network for performing its work. The separation of market/operation fees 80 | matches the separation of roles. Changing this may damage existing businesses. 81 | Thus this BSIP could be a bad idea from this perspective. Also note that the 82 | network can profit from market fees by setting them on committee-owned tokens. 83 | 84 | * This would be another motivation for businesses building on top of BitShares 85 | to get involved in the parameter governance process. The percentage can be 86 | `0` if it is more appropriate. 87 | 88 | * Asset owners can specify a zero market fee percentage to get around the fee 89 | sharing, while still profiting by setting a higher deposit/withdrawal fee. 90 | It is uncommon nowadays probably because it is less convenient or attractive 91 | for their customers. 92 | 93 | * Another strategy is to charge a network market fee globally, independent of 94 | what the asset owner decides. It essentially removes the option to not set 95 | a fee from asset owners, which kills some freedom and would hinder non-profit 96 | use of the platform. 97 | 98 | * It is possible that committee-account would accumulate a lot of tokens with no 99 | value and tokens which are unable or hard to be used to pay for development. 100 | It is a side effect. Hopefully there will be quite some usable tokens. 101 | The committee will have to do some work to manage the tokens anyway. 102 | 103 | * The committee will be accumulating tokens which could potentially be used or 104 | not used for any purpose. In other words, this BSIP as currently written does 105 | not stipulate how those tokens will or will not be used by the committee. 106 | 107 | # Non-Technical Summary 108 | 109 | This BSIP adds a tool for the committee to impose a fee on market trading 110 | fees for all assets which enabled market trading fee, thus it can increase income 111 | for the network to support its development. It may 112 | hinder businesses relying on market fees if the committee-decided fee is high. 113 | The committee may need some efforts to decide on an appropriate value of the parameter and manage the income. 114 | 115 | # Copyright 116 | 117 | This document is placed in the public domain. 118 | 119 | # See Also 120 | 121 | * https://github.com/bitshares/bsips/issues/194 122 | 123 | # Voting outcome 124 | Approved since January 2020. 125 | ![image](https://user-images.githubusercontent.com/33128181/72417817-f2a9b480-3779-11ea-92e9-c267922ca33a.png) 126 | -------------------------------------------------------------------------------- /bsip-0087.md: -------------------------------------------------------------------------------- 1 | BSIP: 0087 2 | Title: Force Settlement Fee 3 | Authors: 4 | Jerry Liu bitcrab@qq.com 5 | Status: Installed 6 | Type: Protocol 7 | Created: 2020-02-23 8 | Discussion: https://github.com/bitshares/bsips/issues/260 9 | Worker: TBD 10 | 11 | # Abstract 12 | This BSIP provide a solution to charge fee from force settlement. 13 | 14 | # Motivation 15 | Force settlement is an important part in smartcoin design, it provides the power to smartcoin holders to ask for collaterals with reference to feed price, and then strengthens the peg of smartcoin. 16 | 17 | The community continuously optimize the rules of smartcoin to balance the interests of relevant parties, taking bitCNY as an example, at the beginning the rules focus more on smartcoin peg but care less on debt position owners’ interests, change are done to give debt position owners more protection, the force settlement offset has been changed from 0 to 2%, the max settlement volume per maintenance period has been changed from no limit to 0.5% of smartcoin supply. 18 | 19 | In the bull market at 2017, thanks to the help of magicwallet, bitCNY has played an important role in connecting CNY fiat and BTS-DEX, some projects selected BTS-DEX as the platform for token trading and bitCNY as the base currency. Things chanegd after implementation of BSIP76 and BAIP2, as these 2 proposals focus more on resisting shorting attack to BTS at the cost of lessening the peg, the difficult choice is made by community at the moment that shorting attack may lead BTS price to zero, after that bitCNY is more a trading asset/derivative in BTS-DEX than a stablecoin, it will still play a great role in leveraging and risk controlling in BTS ecosystem, however it will not be an always exactly pegged stablecoin. 20 | 21 | At the same time, BTS community continuously review the strategy, one strong consensus is that the system need to charge more fee at the suitable transactions to increase system income to pay public expenditures and buy back BTS. BSIP74, BSIP86 all come out at this background, it is also necessary to provide the possibility to charge from force settlement. 22 | 23 | In the past several weeks, force settlement happened more intensively than before, the background is that the crypto market seemly switched from bear to bull, and BTS price went above 0.22CNY - which is the voted threshold per BSIP76, at some time the frequently happened force settlements made the lowest debt position collateral ratio even higher than 3, this phenomenon triggered warm discussion, almost all the users agree that the settler need to pay more cost while executing force settlement, and the cost will be paid to system as fee. 24 | 25 | Surely this BSIP just provide the tool to charge from froce settlement. whether the charge will go alive depends on the decision of the smartcoin owner. 26 | 27 | # Rationale 28 | Force settlement fee can be seen as to pay part of the cost for smartcoin supply, stabilization and also the liquidation of collaterals, it is irrelevant to market fee sharing. 29 | To ensure the debt positions can always be closed with suffcient smartcoin, it is more feasible to cut off part of the traded collaterals as fee, instead of smartcoin. 30 | 31 | # Specification 32 | Add one new parameter Force Settlement Fee Percentage(FSFP) for each smartcoin, which is controlled by the smartcoin owner. 33 | 34 | FSO is Force Settlement Offset of the smartcoin. 35 | 36 | When a force settlement is executed, the buyer sells smartcoin with quantity `X` and get collateral in quantity `X*(1-FSO)*(1-FSFP)/feed price price*`, the settled debt position owner sells collateral in quantity `X*(1-FSO)/feed price*` and get smartcoin in quantity `X`, the delta in paid and received collateral in quantity `X*FSFP*(1-FSO)/feed price*` will be paid to the owner of the smartcoin as force settlement fee. 37 | 38 | In this scenario, as a price offset parameter, FSO is irrelevant to fee charging, it just define `force settlement price = feed price/(1-FSO)`. and the force settlement fee is paid in collateral and the amount is calculated out based on `force settlement price` and `FSFP`. 39 | 40 | # Copyright 41 | This document is placed in the public domain. 42 | --------------------------------------------------------------------------------