Skip to content
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

Merged
merged 9 commits into from Mar 12, 2024
Merged

FI: Add swapping events #1764

merged 9 commits into from Mar 12, 2024

Conversation

lemunozm
Copy link
Contributor

@lemunozm lemunozm commented Mar 8, 2024

Description

  • Add SwapCreated and SwapFullfilled events from the PoV of FI.

Should be merged before RU

@lemunozm lemunozm added I3-annoyance The code behaves as expected, but "expected" is an issue. D0-ready Pull request can be merged without special precaution and notification. Q3-medium Can be done with good experience in the language, but little knowledge of the codebase. P9-drop-everything Everyone should address this issue now. labels Mar 8, 2024
Copy link
Contributor Author

@lemunozm lemunozm left a 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.

Comment on lines +227 to +230
remaining: Swap {
amount_out: status.pending,
..swap.clone()
},
Copy link
Contributor Author

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.

Copy link
Contributor

@wischli wischli left a 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.

Comment on lines +122 to +123
/// Ratio used to swap `swapped_out` into `swapped_in`
pub ratio: Ratio,
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@lemunozm
Copy link
Contributor Author

lemunozm commented Mar 8, 2024

Moreover, it would be nice to assert the newly added events in a unit test.

Agree! I'll do it in a follow-up PR to not block this in case I have no time to finish them

@lemunozm
Copy link
Contributor Author

lemunozm commented Mar 8, 2024

Modified to return always the market ratio in a fulfilled event even when it comes from a cancelation.

wischli
wischli previously approved these changes Mar 11, 2024
Copy link
Contributor

@wischli wischli left a comment

Choose a reason for hiding this comment

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

LGTM!

@lemunozm
Copy link
Contributor Author

We should not merge it yet. There are some requested changes from slack

Comment on lines +272 to +297
#[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,
},
}
Copy link
Contributor Author

@lemunozm lemunozm Mar 11, 2024

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.

Copy link
Contributor

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?

Copy link
Contributor Author

@lemunozm lemunozm Mar 11, 2024

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 👍🏻

Copy link
Contributor

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

Copy link
Collaborator

@mustermeiszer mustermeiszer left a 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

@wischli
Copy link
Contributor

wischli commented Mar 11, 2024

Just RC as I want to see before merge

Just triggered a WASM generation and can update Dev later.

Copy link
Collaborator

@mustermeiszer mustermeiszer left a 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.

Comment on lines +223 to +245
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()
},
})
}
Copy link
Collaborator

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?

Copy link
Contributor Author

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 and swapped 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 and swapped 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 and swapped 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.

Copy link
Collaborator

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!

@lemunozm lemunozm merged commit cd1d36d into main Mar 12, 2024
12 checks passed
@lemunozm lemunozm deleted the fi/swap-events branch March 12, 2024 11:53
@wischli wischli mentioned this pull request Mar 12, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D0-ready Pull request can be merged without special precaution and notification. I3-annoyance The code behaves as expected, but "expected" is an issue. P9-drop-everything Everyone should address this issue now. Q3-medium Can be done with good experience in the language, but little knowledge of the codebase.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants