Design to facilitate cross-collateral margin

[mzs-dev]

Is it a conscious design decision to only allow positions using the same collateral as the target token custody? I belive it's important to facilitate cross-collateral margin for short positions where a trader would want to have a different collateral than the one s/he's is taking a position in.

[askibin]

Collateral is always converted to USD upon deposit, this is similar to GMX: "When you open a position or deposit collateral, a snapshot of the USD price of your collateral is taken, so e.g. if your collateral is 0.1 ETH and the price of ETH is 3523.30 at the time, then your collateral is 352.33 USD and will not change even if the price of ETH changes." So you don't really choose which token will be used for maintaining a position but rather what you initially deposit.

I agree that you might want to deposit, let's say BONK but go long SOL. Frontend that we are building will support that by adding a swap instruction into the same transaction. GMX also charges a swap fee in such cases, so it will work similarly.

[mzs-dev]

I totally get the idea but I'm a bit confused with the lock_funds call here:

perpetuals/programs/perpetuals/src/instructions/open_position.rs

Line 214 in c467cf3

pool.lock_funds(params.size, custody)?;

When shorting, shouldn't the locked_funds be updated on a stable_coin custody in the pool instead of the target token custody for an amount equivalent to the size of the position, to be reserved for pnl payoff?

[askibin]

Oh, you were talking about that part. Yes, I have that on my list, but still trying to wrap my head around it. The problem is that there could be multiple stablecoins in the pool with different available amounts and different token ratios. So an ideal approach would be to pass all such custodies and determine what amount should be locked in one or multiple custodies that will keep the token ratio as optimal as possible in the case of profit payoff. And this also needs to be recorded to the position account, so it can be properly unlocked later. I might go with a simplified solution and just lock tokens in custodies selected by the frontend (automatically), I need to think about it.

[mzs-dev]

Great!
GMX allows the user to select any collateral token (from listed stable coins) when opening a short position and we will have to do the same as you pointed out and also record it as part of the position state
Can help with that, will be creating a PR on that affect...
Any ideas to idenitfy stable_coin token custodies for validation on program? May need to add a flag as part of the custody state.

[askibin]

sounds good, I added is_stable flag to the custody in the latest commit