Skip to main content

Module interface

Module interface 

Source
Expand description

Cross-program ABI interface for read-only foreign account access.

The jiminy_interface! macro generates a lightweight, read-only struct that can decode accounts owned by another program. It produces the same LAYOUT_ID as a matching zero_copy_layout! declaration, enabling cross-program layout verification without sharing crate dependencies.

§Usage

Program B wants to read Program A’s Vault account:

use jiminy_core::jiminy_interface;
use jiminy_core::account::{AccountHeader, Pod, FixedLayout};
use jiminy_core::abi::LeU64;
use pinocchio::Address;

const PROGRAM_A: Address = [0u8; 32]; // Program A's address

jiminy_interface! {
    /// Read-only view of Program A's Vault account.
    pub struct Vault for PROGRAM_A {
        header:    AccountHeader = 16,
        balance:   LeU64         = 8,
        authority: Address       = 32,
    }
}

// In your instruction handler:
fn process(accounts: &[AccountView]) -> ProgramResult {
    let verified = Vault::load_foreign(&accounts[0])?;
    let vault = verified.get();
    // read vault.balance, vault.authority, etc.
    Ok(())
}

§What gets generated

  • #[repr(C)] struct with typed fields
  • LAYOUT_ID matching the original zero_copy_layout! definition
  • LEN constant
  • overlay / read (immutable only, no mutable access)
  • load_foreign with Tier 2 owner + layout_id validation
  • Const field offsets and split_fields (immutable only)

§Version

By default, version = 1 is used in the LAYOUT_ID hash. If the foreign program uses a different version, specify it explicitly:

jiminy_interface! {
    pub struct PoolV2 for PROGRAM_A, version = 2 { ... }
}

§Design

Interface types are intentionally restricted:

  • No load (Tier 1) — you don’t own this account
  • No overlay_mut — foreign accounts are read-only
  • No split_fields_mut — same reason
  • No load_checked — discriminator/version are owner concerns