Struct PositionCut

pub struct PositionCut<'info> {

    pub authority: Signer<'info>,
    pub owner: UncheckedAccount<'info>,
    pub user: AccountLoader<'info, UserHeader>,
    pub store: AccountLoader<'info, Store>,
    pub token_map: AccountLoader<'info, TokenMapHeader>,
    pub oracle: AccountLoader<'info, Oracle>,
    pub market: AccountLoader<'info, Market>,
    pub order: AccountLoader<'info, Order>,
    pub position: AccountLoader<'info, Position>,
    pub event: AccountLoader<'info, TradeData>,
    pub long_token: Box<Account<'info, Mint>>,
    pub short_token: Box<Account<'info, Mint>>,
    pub long_token_escrow: Box<Account<'info, TokenAccount>>,
    pub short_token_escrow: Box<Account<'info, TokenAccount>>,
    pub long_token_vault: Box<Account<'info, TokenAccount>>,
    pub short_token_vault: Box<Account<'info, TokenAccount>>,
    pub claimable_long_token_account_for_user: Box<Account<'info, TokenAccount>>,
    pub claimable_short_token_account_for_user: Box<Account<'info, TokenAccount>>,
    pub claimable_pnl_token_account_for_holding: Box<Account<'info, TokenAccount>>,
    pub system_program: Program<'info, System>,
    pub token_program: Program<'info, Token>,
    pub associated_token_program: Program<'info, AssociatedToken>,
    pub chainlink_program: Option<Program<'info, Chainlink>>,
    pub event_authority: AccountInfo<'info>,
    pub program: AccountInfo<'info>,
}

The accounts definitions for the liquidate and auto_deleverage instructions.

Remaining accounts expected by this instruction:

• 0..N. [] N feed accounts, where N represents the total number of unique tokens in the market.

Warnings

Because token accounts can be frozen by token’s freeze authority (although extremely unlikely), keepers may need to be aware of the following two issues when using the “position cut” instructions:

Escrow Accounts Are Frozen

If escrow accounts are frozen, the “position cut” instruction will fail to execute due to a transfer failure.

However, token accounts cannot be frozen before they are initialized. To avoid this issue, the keeper only needs to ensure that the escrow accounts creation instruction and the “position cut” instruction are within the same transaction.

Claimable Accounts Are Frozen

If the funding fee of a position is paid with secondary output tokens (pnl tokens), it may generate claimable funds belonging to the holding address. Alternatively, if a negative position’s price impact is too high, it may generate a price_impact_diff that results in claimable funds transferred to the owner. If claimable funds are generated and the corresponding claimable accounts are frozen at this time, the “position cut” instruction may also fail to execute due to transfer failure.

Since claimable accounts may be created before executing the “position cut” instruction, in such cases, the keeper needs to wait until new claimable accounts can be created (when the recent time window changes, causing the address to change) before re-executing the “position cut” instruction.

In the future, we may avoid directly using token accounts to receive these claimable funds to prevent this issue.

Fields

authority: Signer<'info>

Authority.

owner: UncheckedAccount<'info>

The owner of the position. CHECK: only used to receive fund.

user: AccountLoader<'info, UserHeader>

User Account.

store: AccountLoader<'info, Store>

Store.

token_map: AccountLoader<'info, TokenMapHeader>

Token map.

oracle: AccountLoader<'info, Oracle>

Buffer for oracle prices.

market: AccountLoader<'info, Market>

Market.

order: AccountLoader<'info, Order>

The order to be created.

position: AccountLoader<'info, Position>

event: AccountLoader<'info, TradeData>

Trade event buffer.

long_token: Box<Account<'info, Mint>>

Long token.

short_token: Box<Account<'info, Mint>>

Short token.

long_token_escrow: Box<Account<'info, TokenAccount>>

The escrow account for long tokens.

short_token_escrow: Box<Account<'info, TokenAccount>>

The escrow account for short tokens.

long_token_vault: Box<Account<'info, TokenAccount>>

Long token vault.

short_token_vault: Box<Account<'info, TokenAccount>>

Short token vault.

claimable_long_token_account_for_user: Box<Account<'info, TokenAccount>>

claimable_short_token_account_for_user: Box<Account<'info, TokenAccount>>

claimable_pnl_token_account_for_holding: Box<Account<'info, TokenAccount>>

system_program: Program<'info, System>

Initial collatearl token vault. The system program.

token_program: Program<'info, Token>

The token program.

associated_token_program: Program<'info, AssociatedToken>

The associated token program.

chainlink_program: Option<Program<'info, Chainlink>>

Chainlink Program.

event_authority: AccountInfo<'info>

CHECK: Only the event authority can invoke self-CPI

program: AccountInfo<'info>

CHECK: Self-CPI will fail if the program is not the current program

Trait Implementations

impl<'info> Accounts<'info, PositionCutBumps> for PositionCut<'info>

where 'info: 'info,

fn try_accounts( __program_id: &Pubkey, __accounts: &mut &'info [AccountInfo<'info>], __ix_data: &[u8], __bumps: &mut PositionCutBumps, __reallocs: &mut BTreeSet<Pubkey>, ) -> Result<Self>

Returns the validated accounts struct. What constitutes “valid” is program dependent. However, users of these types should never have to worry about account substitution attacks. For example, if a program expects a Mint account from the SPL token program in a particular field, then it should be impossible for this method to return Ok if any other account type is given–from the SPL token program or elsewhere.

impl<'info> AccountsExit<'info> for PositionCut<'info>

where 'info: 'info,

fn exit(&self, program_id: &Pubkey) -> Result<()>

program_id is the currently executing program.

impl<'info> Bumps for PositionCut<'info>

where 'info: 'info,

type Bumps = PositionCutBumps

Struct to hold account bump seeds.

impl<'info> ToAccountInfos<'info> for PositionCut<'info>

where 'info: 'info,

fn to_account_infos(&self) -> Vec<AccountInfo<'info>>

impl<'info> ToAccountMetas for PositionCut<'info>

fn to_account_metas(&self, is_signer: Option<bool>) -> Vec<AccountMeta>

is_signer is given as an optional override for the signer meta field. This covers the edge case when a program-derived-address needs to relay a transaction from a client to another program but sign the transaction before the relay. The client cannot mark the field as a signer, and so we have to override the is_signer meta field given by the client.