New operation: limit_order_update_operation, so that traders can update their limit orders directly
operation_type = 77
default fee 0.375 BTS (slightly lower than the current order creation fee on the BitShares Mainnet, and applicable to all refund mechanisms)
struct limit_order_update_operation : public base_operation
{
struct fee_params_t {
uint64_t fee = ( GRAPHENE_BLOCKCHAIN_PRECISION * 3 ) / 8;
};
asset fee;
account_id_type seller;
limit_order_id_type order;
optional<price> new_price;
optional<asset> delta_amount_to_sell;
optional<time_point_sec> new_expiration;
/// Automatic actions when the limit order is filled or partially filled
optional< vector< limit_order_auto_action > > on_fill;
extensions_type extensions;
};
NOTE 1:
The base amount in the new price is limited by an estimation of the order's maximum amount to sell. This is to mitigate against inappropriate price manipulation, although not completely avoid it.
NOTE 2:
When updating a limit order with a non-zero deferred fee, we charge the owner a small fee equal to order_cancel_fee * order_update_fee / order_create_fee (not higher than the deferred fee), and refund the remainder in the deferred fee, the deferred fee is then refreshed with the new operation fee paid.
The small fee is to mitigate potential transaction spam issues.
The deferred fee is used for all refund mechanisms.
Side effect:
Assuming that order update fee will be lower than order creation fee, traders can create an order and then update it immediately to reduce costs, both for making and taking.
NOTE 3:
Since the price can be modified, sell_price.base.amount is no longer always equal to the total amount allocated to the limit order. In the meanwhile, a new data field filled_amount is added to limit_order_object in PR #2776, this way users can still know the total amount.
PR for #1604.
Based on @nathanielhourt's work for #1604 (see https://github.com/nathanielhourt/bitshares-2/pull/1).
Changes:
New operation:
limit_order_update_operation
, so that traders can update their limit orders directlyoperation_type
=77
default fee
0.375 BTS
(slightly lower than the current order creation fee on the BitShares Mainnet, and applicable to all refund mechanisms)NOTE 1: The
base
amount in the new price is limited by an estimation of the order's maximum amount to sell. This is to mitigate against inappropriate price manipulation, although not completely avoid it.NOTE 2: When updating a limit order with a non-zero deferred fee, we charge the owner a small fee equal to
order_cancel_fee * order_update_fee / order_create_fee
(not higher than the deferred fee), and refund the remainder in the deferred fee, the deferred fee is then refreshed with the new operation fee paid. The small fee is to mitigate potential transaction spam issues. The deferred fee is used for all refund mechanisms.Side effect: Assuming that order update fee will be lower than order creation fee, traders can create an order and then update it immediately to reduce costs, both for making and taking.
NOTE 3: Since the price can be modified,
sell_price.base.amount
is no longer always equal to the total amount allocated to the limit order. In the meanwhile, a new data fieldfilled_amount
is added tolimit_order_object
in PR #2776, this way users can still know the total amount.NOTE 4: Please see https://github.com/bitshares/bitshares-core/pull/2749 for more info about automatic actions (Order-Sends-Order).