Struct SignRelation

pub struct SignRelation<'info> {
    pub from: Signer<'info>,
    pub provider: Account<'info, Provider>,
    pub tree: AccountInfo<'info>,
    pub tree_controller: Account<'info, Controller>,
    pub payer: Signer<'info>,
    pub ac_program: Program<'info, SplAccountCompression>,
    pub noop_program: Program<'info, Noop>,
    pub graph_program: Program<'info, Graph>,
}

Fields

from: Signer<'info>

provider: Account<'info, Provider>

tree: AccountInfo<'info>

CHECK: key is checked

tree_controller: Account<'info, Controller>

CHECK: seeds are checked

payer: Signer<'info>

ac_program: Program<'info, SplAccountCompression>

noop_program: Program<'info, Noop>

graph_program: Program<'info, Graph>

Implementations

impl<'info> SignRelation<'info>

pub fn add_relation_ctx( &self, ) -> CpiContext<'_, '_, '_, 'info, AddRelation<'info>>

Trait Implementations

impl<'info> Accounts<'info> for SignRelation<'info>

where 'info: 'info,

fn try_accounts( program_id: &Pubkey, accounts: &mut &[AccountInfo<'info>], ix_data: &[u8], __bumps: &mut BTreeMap<String, u8>, __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 SignRelation<'info>

where 'info: 'info,

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

program_id is the currently executing program.

impl<'info> ToAccountInfos<'info> for SignRelation<'info>

where 'info: 'info,

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

impl<'info> ToAccountMetas for SignRelation<'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.