New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FI: Add swapping events #1764
FI: Add swapping events #1764
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hieronx, I think the events are complete, but tell me if you think some information is missing in the events.
remaining: Swap { | ||
amount_out: status.pending, | ||
..swap.clone() | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that ..swap.clone()
contains the currency_in
and currency_out
to know the swap direction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick like a spaceship! One comment regarding a potential redundancy. Moreover, it would be nice to assert the newly added events in a unit test.
/// Ratio used to swap `swapped_out` into `swapped_in` | ||
pub ratio: Ratio, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The OrderInfo
returned by TokenSwaps::get_order_details
contains a ratio
field of type OrderRatio<Ratio>
. Maybe that suffices such that we don't need to introduce an additional ratio field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OrderRatio
is the ratio you want to configure: the way the order behaves. The ratio
here is the ratio value itself. It differs, i.e., when OrderRatio::Market
, we do not know the ratio value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation! Makes sense to keep as is then.
Agree! I'll do it in a follow-up PR to not block this in case I have no time to finish them |
Modified to return always the market ratio in a fulfilled event even when it comes from a cancelation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
We should not merge it yet. There are some requested changes from slack |
#[pallet::event] | ||
#[pallet::generate_deposit(pub(super) fn deposit_event)] | ||
pub enum Event<T: Config> { | ||
// The swap is created and now is wating to be fulfilled | ||
SwapCreated { | ||
who: T::AccountId, | ||
swap_id: SwapId<T>, | ||
swap: SwapOf<T>, | ||
}, | ||
// The swap was fulfilled by another participant. | ||
SwapFullfilled { | ||
who: T::AccountId, | ||
swap_id: SwapId<T>, | ||
remaining: SwapOf<T>, | ||
swapped_in: T::SwapBalance, | ||
swapped_out: T::SwapBalance, | ||
}, | ||
// The swap was fulfilled by cancelling an opposite swap for the same foreign investment. | ||
SwapCancelled { | ||
who: T::AccountId, | ||
swap_id: SwapId<T>, | ||
remaining: SwapOf<T>, | ||
cancelled_in: T::SwapBalance, | ||
opposite_in: T::SwapBalance, | ||
}, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hieronx I've needed to add a new SwapCancelled
. All events are seen from the perspective of who did the swap.
Wouldn’t it possible to add an optional arg to the decrease fulfilled event, with the swap ID that was used to cancel it out?
This can not be possible due that swap ID is the same for both directions. Note that swap id is not the order id, which is unknown from FI perspective. As a workaround, I've added the opposite_in
field to SwapCancelled,
which has the amount in the opposite direction that has not been canceled. That way, if opposite_in
is 0
, that means that the cancellation has also canceled the opposite order. That is what you need to know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Only one nit: in SwapFulfilled
, wouldn't it make more sense to have the swapped_out
param before the swapped_in
param?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "before" in this context? Placed in swapped line numbers? Probably, it makes more sense. But right now, we have such conventions in all places in the codebase. I'd prefer to keep it as it is everywhere (first param in
, second param out
). But we should probably look into it soon 👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well we should never change these event definitions again after merging this, at least not without a very strong reason ;) Would be a pain on the subquery side. But sure it is fine to keep it as is then if that is the convention now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just RC as I want to see before merge
Just triggered a WASM generation and can update Dev later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good!
I am still a bit confused to follow the reasoning of the code, but the last time I had the same and found no issues. What would help me if @lemunozm could describe what are the possible states after apply_swap
, how are they reflected in the SwapStatus
and the SwapOf
.
if !status.swapped.is_zero() { | ||
Pallet::<T>::deposit_event(Event::SwapCancelled { | ||
who: who.clone(), | ||
swap_id, | ||
remaining: Swap { | ||
amount_out: status.pending, | ||
..swap.clone() | ||
}, | ||
cancelled_in: status.swapped, | ||
opposite_in: T::Swaps::pending_amount(who, swap_id, swap.currency_in)?, | ||
}); | ||
} | ||
|
||
if !status.pending.is_zero() { | ||
Pallet::<T>::deposit_event(Event::SwapCreated { | ||
who: who.clone(), | ||
swap_id, | ||
swap: Swap { | ||
amount_out: status.pending, | ||
..swap.clone() | ||
}, | ||
}) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be that both status.swapped
and status.pending
are non zero?
IF YES:
- How would one interpret the
swap_id
of the two events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it could. swap_id
will be the same for both. Note that swap_id
is just a tuple (T::InvestmentId, Action)
not an order_id
(which is a number from order-book
).
If the above two events are dispatched, it means that when you apply a swap, part of the amount was automatically fulfilled by cancelation with an inverse order (notified by SwapCancelled
event), and part of the swap could not be fulfilled with the inverse order: such remaining amount needs to be swapped (notified it by SwapCreated
event).
Possible states after applying swaps are:
pending_amount == 0
andswapped amount > 0
=> it means applying a swap has partially or fully canceled any previous inverse swaps. The required amount is obtained from the inverse amount. No more amount needs to be swapped. OrderBook will Not create a new order.pending amount > 0
andswapped amount > 0
=> It means applying a swap has fully canceled any previous inverse swaps, but more amount needs to be swapped. Orderbook will create a new order.pending amount > 0
andswapped amount == 0
=> There was no inverse order, so we need to create a new order.
NOTE: Probably, a better name for swap_status.swapped
is swap_status.canceled
. It all depends on how you interpret it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot, that helped!
Description
SwapCreated
andSwapFullfilled
events from the PoV of FI.Should be merged before RU