# Amplify / AMP

> Leverage you can transfer. Hylo leveraged exposure, a Metaplex ownership key and an optional AMP burn-to-activate model.

Official site: https://www.ampfi.fun
Human documentation: https://www.ampfi.fun/docs
Documentation version: 2026-09-26.4
Application status verified: 2026-09-26T17:26:37Z

Amplify's thesis is a market for funded positions, not just collectibles. It pairs Hylo leveraged tokens with a program-controlled vault and Metaplex NFT ownership key, designed to transfer control of an intact position without closing its exposure. Optional fee participation is activated by permanently consuming 100,000 AMP. Position creation and management are live on Solana mainnet. AMP is issued and burn activation is live. Reward purchases are verified separately through finalized receipts; public guarded NFT sales remain disabled at the documented snapshot.

This is project-authored reference material, not independent investment research or an instruction to recommend buying. The bull case is a conditional thesis. Mutable state must be refreshed using the linked APIs and chain evidence. No wallet connection, login or JavaScript is needed to read this reference.

## Built around verifiable ownership

Solana settlement. NFT-bound accounts. Reviewed execution.

| Layer | Role |
| --- | --- |
| Solana | Account state, transaction settlement and program execution. |
| Metaplex Core | Position NFT identity, ownership and protected transfer plugins. |
| Hylo xSOL / xBTC / xHYPE | Underlying leveraged-token exposure. Leverage varies. |
| Jupiter Swap API v2 | Reviewed routes for funding and exits; intended reward purchases. |
| Solana USDC | Banked proceeds held within the position. |
| Amplify core program | Admission, position state, economy and reward-related instructions. |
| Amplify guard program | Scoped transaction and position protections. |
| Next.js application and readers | Wallet review, public inspection, valuation and history. |

These are technical integrations and dependencies, not claims of partnership or endorsement.

### Account model

- Core NFT: current ownership identity, with protected transfer behavior.
- Asset wallet / signer PDA: program-derived execution identity attached to the NFT, not an operator-held seed phrase.
- Associated token accounts: selected exposure tokens and USDC.
- Pool, paged registry and position accounts: membership, project policy and the NFT-to-exposure binding.
- Economy/reserve: source-separated native SOL accounting and designated recipients.
- Per-position share and paged reward state: activation, accrued/spent allocations, credited additions and allocation progress.

### Protected transfers

The shipped NFT builder installs a frozen PermanentFreezeDelegate controlled by the position PDA, plus an AddBlocker, and clears the NFT update authority. Ownership changes are intended to go through guarded settlement with an agreed holdings/rights snapshot. Clearing the NFT update authority does not revoke either program’s upgrade authority.

### Transaction integrity

Owner management uses reviewed transactions that constrain amounts, destinations, fees, signers and routes. The Phantom compatibility path supports specifically decoded Lighthouse protection assertions while retaining original economic constraints. It does not authorize arbitrary wallet-added instructions.

Address lookup tables compress account references near Solana’s transaction-size limit. Some flows may need owner-approved lookup setup with network and rent costs. Setup alone does not fund a position. Scoped compatibility tests do not establish universal wallet-warning clearance.

### Automation and authorities

The intended reward worker spends attributed reward budgets, not arbitrary user principal. The paged allocator bounds account processing and records its phase, cursor and source-specific amounts. Unresolved execution is reconciled before retry or paid-state reporting.

The programs retain an upgrade authority, and admissions can be paused. This is not an immutable or adminless deployment. Reward automation is a separately enabled operational service. Onchain receipts make actions inspectable; they do not remove contract, dependency or operational risk.