MIMD 0000: Schedule base layer instructions trough CPI

[GabrielePicco]

Summary

We currently support 2 ways to settle state to the base layer

1. Committing delegated accounts

  commit_accounts(
      &ctx.accounts.payer,
      vec![&ctx.accounts.counter.to_account_info()],
      &ctx.accounts.magic_context,
      &ctx.accounts.magic_program,
  )?;

2. Committing and undelegating accounts

  commit_and_undelegate_accounts(
      &ctx.accounts.payer,
      vec![&ctx.accounts.counter.to_account_info()],
      &ctx.accounts.magic_context,
      &ctx.accounts.magic_program,
  )?;

• In several scenarios, the cient await on the state to settle on the base layer, and then trigger a transaction on the base layer (e.g. minting an NFT based on a position updated in an ER). While this is viable, it's very unergonomic.

We could extend the API to support scheduling instructions that would be atomically executed with the commit or commit_and_undelegate:

• commit_accounts_with_ixs
• commit_and_undelegate_with_ixs

---

E.g:

 commit_accounts_with_ixs(
     &ctx.accounts.payer,
     vec![&ctx.accounts.counter.to_account_info()],
     &ctx.accounts.magic_context,
     &ctx.accounts.magic_program,
     vec![mint_istruction]
 )?;

The validator would prepare and settle the state as we are currently doing, but the scheduled instructions would be added to the tx containing the last finalize

Motivation

We would have 2 new primitives that allows to:

1. Commit/do something on the base layer atomically
2. Commit/Undelegate/do something on the base layer/Re-Delegate atomically

Some uses cases that this will unlock:

• Limit orders
• Minting or doing swaps atomically based on state in the ER
• ...

Security Considerations

• Validator pubkey should not be part of the scheduled ixs, or there is a risk that it could get drained

[taco-paco]

Should we be so closely connected to commit action? Could it be ER->L1 message(transaction)?

That would mean that Users could send Transaction to ER. We would batch them in MagicContext and then execute at once.

Thus:
You still able to do above + extra functionality and cheaper for user.

[GabrielePicco]

Closing as implemented