lez-programs/programs/amm/src/lib.rs

//! The AMM Program implementation.

pub use amm_core as core;

pub mod add;
pub mod create_oracle_price_account;
pub mod create_price_observations;
pub mod initialize;
pub mod new_definition;
pub mod remove;
pub mod swap;
pub mod sync;
pub mod update_config;

mod tests;
chore: initial repository setup for programs 2026-03-17 18:08:53 +01:00			`//! The AMM Program implementation.`

			`pub use amm_core as core;`

			`pub mod add;`
feat(amm): create TWAP oracle price account on behalf of the pool Add a CreateOraclePriceAccount instruction mirroring CreatePriceObservations: anyone can register the consumer-facing OraclePriceAccount for a pool feed, and the AMM authorizes the pool as the price source via its pool PDA seed through a single chained call to the configured TWAP oracle program. 2026-06-23 17:28:22 +02:00			`pub mod create_oracle_price_account;`
feat(amm): create TWAP price observations on behalf of the pool Add a `CreatePriceObservations` instruction that registers a TWAP price-observations account for a pool over a time window, via a chained call to the configured TWAP oracle program. The pool acts as the price source: the AMM authorizes it with its pool PDA seed so the oracle ties the feed to that pool. The feed's initial tick is read from the pool's authoritative `CurrentTickAccount` (validated against its pool-derived PDA) rather than being supplied by the caller, so the feed cannot be seeded at a forged price — mirroring what `RecordTick` does. The clock is verified to be the canonical 1-block LEZ clock, and creation is rejected if the observations account already exists. To support the chained call, `AmmConfig` and the `Initialize` instruction are extended with a `twap_oracle_program_id` that the instruction reads. 2026-06-18 09:01:10 +02:00			`pub mod create_price_observations;`
feat(amm): add Initialize instruction with config-gated chained calls Introduce a singleton AMM configuration account, a PDA derived from the constant "CONFIG" seed, created once via a new `Initialize` instruction. The config stores the Token Program ID the AMM issues every chained call to, replacing the previous behavior of trusting the program owner of a caller-supplied holding. The config account's existence is the Program's initialization gate: the chained-call instructions (new_definition, add_liquidity, remove_liquidity, swap_exact_input, swap_exact_output) now take the config as their first account, validate it against `compute_config_pda(self_program_id)`, and read the Token Program ID from it on demand — rejecting calls until the Program is initialized. Vaults and user holdings are asserted to match the configured Token Program. sync_reserves is left ungated, as it cannot act on a pool that could not have existed before initialization. - amm_core: AmmConfig type, compute_config_pda/_seed, Initialize variant - amm: initialize.rs + config threading through chained-call instructions - guest: initialize instruction; config + self_program_id on gated calls - tests: config fixtures, init-gate unit tests, end-to-end Initialize VM test 2026-06-17 16:29:30 +02:00			`pub mod initialize;`
chore: initial repository setup for programs 2026-03-17 18:08:53 +01:00			`pub mod new_definition;`
			`pub mod remove;`
			`pub mod swap;`
feat(amm): add SyncReserves instruction Adds a new `SyncReserves` instruction that updates a pool's recorded reserves to match the actual vault balances. This allows the pool to absorb donations (direct token transfers to vaults) without breaking the invariant — only upward adjustments are permitted; vaults may not be under-collateralized relative to reserves. Vault reading helpers (`read_fungible_holding`, `read_vault_fungible_balances`) are implemented in `amm_core` so they can be shared across instructions without crossing crate boundaries. 2026-04-08 10:57:47 -03:00			`pub mod sync;`
feat(amm): add admin authority and UpdateConfig instruction Add an admin authority to the AMM config so configuration can be changed after initialization. AmmConfig gains an `authority` field, set by Initialize, and a new UpdateConfig instruction lets that admin change config values. UpdateConfig is access-controlled: the authority account must equal the stored config.authority and be passed authorized (signed). Both fields are optional — token_program_id updates the chained-call token program, and new_authority transfers admin control to a different account. Without this gate any caller could repoint the AMM at a malicious token program. 2026-06-18 16:46:38 +02:00			`pub mod update_config;`
chore: initial repository setup for programs 2026-03-17 18:08:53 +01:00
			`mod tests;`