Ako postavit Solana escrow program pre marketplace sluzby (Anchor blueprint)

Mnoho timov chce “nieco uzitocne” na Solane a hned skoci do tokenomiky. Lepsi prvy produkt je casto nudny, ale biznisovo silny: escrow.

Ak prevadzkujes service marketplace (design, konzultacie, development, AI tasky), potrebujes jednu klucovu garanciu:

• buyerove prostriedky su rezervovane,
• seller dostane vyplatu az po akceptacii,
• disputy a timeouty su deterministicke.

Solana je na toto dobra volba, lebo fee su male a vykon staci na bezny produktovy UX.

Toto je produkcny blueprint postaveny na Anchor pristupe.

1. Produktovy scope (co ma v1 robit)

Udrz prvu verziu uzku:

• vytvorit escrow pre jednu objednavku,
• naplnit escrow stablecoinom (napr. USDC),
• oznacit dodanie,
• buyer potvrdi a uvolni platbu,
• volitelne storno po timeout-e.

Nesnaz sa v rovnakej verzii riesit arbitrazny marketplace, reputacny staking aj fee tokenomiku.

2. Account model

Cisty account model usetri vela bolesti v dalsich releasoch.

#[account]
pub struct Escrow {
    pub escrow_id: u64,
    pub buyer: Pubkey,
    pub seller: Pubkey,
    pub mint: Pubkey,
    pub amount: u64,
    pub fee_bps: u16,
    pub created_at: i64,
    pub delivery_deadline: i64,
    pub status: EscrowStatus,
    pub bump: u8,
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone, PartialEq, Eq)]
pub enum EscrowStatus {
    Created,
    Funded,
    Delivered,
    Released,
    Cancelled,
    Disputed,
}

Design poznamky:

• Pouzivaj PDA escrow vault authority, nikdy nie sukromny key wallet pre custody.
• status prechody drz explicitne.
• Kriticke roly a sumy ukladaj on-chain, never off-chain payloadu.

3. Sada instrukcii

Minimalna, ale kompletna sada:

1. create_escrow(escrow_id, seller, amount, deadline, fee_bps)
2. fund_escrow()
3. mark_delivered(proof_hash)
4. accept_and_release()
5. cancel_after_timeout()
6. raise_dispute(reason_hash)

Toto staci na realne transakcie v produkcii a bezpecny iteracny vyvoj.

4. Kriticke bezpecnostne invarianty

Tieto pravidla musia platit v kazdej instrukcii:

• Prostriedky idu z escrow vaultu iba na povolene adresy.
• accept_and_release moze volat iba buyer.
• mark_delivered moze volat iba seller.
• Timeout storno je povolene az ked Clock::get()?.unix_timestamp > delivery_deadline.
• Stavove prechody su jednosmerne a validovane (Funded -> Delivered -> Released).
• Fee a payout vypocty su checked (ziadne overflow a skryte podtecenia).

Ak toto porusis, dostanes penazne bugy, nie kozmeticke bugy.

5. Ukazka release flow

pub fn accept_and_release(ctx: Context<AcceptAndRelease>) -> Result<()> {
    let escrow = &mut ctx.accounts.escrow;

    require!(escrow.status == EscrowStatus::Delivered, EscrowError::InvalidStatus);
    require!(ctx.accounts.buyer.key() == escrow.buyer, EscrowError::Unauthorized);

    let fee = (escrow.amount as u128)
        .checked_mul(escrow.fee_bps as u128)
        .ok_or(EscrowError::MathOverflow)?
        / 10_000u128;

    let seller_amount = (escrow.amount as u128)
        .checked_sub(fee)
        .ok_or(EscrowError::MathOverflow)?;

    // Transfer seller payout from vault ATA -> seller ATA
    // Transfer fee from vault ATA -> platform fee ATA
    // (Use token program CPI with PDA signer seeds)

    escrow.status = EscrowStatus::Released;
    Ok(())
}

V ukazke nie je cele CPI boilerplate, ale je tam podstata:

• striktna validacia stavu,
• striktna validacia volajuceho,
• checked matematika,
• update stavu az po validnom transfer flow.

6. Off-chain sluzby, ktore stale potrebujes

Smart contract sam o sebe nestaci.

Do produkcie este potrebujes:

• Order API pre business pravidla a metadata,
• Indexer/worker na sledovanie escrow account zmien a signature,
• Reconciliation DB mapovanie on-chain escrow ID na order ID,
• Notification service pre delivery, akceptaciu a timeout upozornenia.

Program zabezpecuje transfer hodnoty. Backend zabezpecuje prevadzkovatelnost.

7. Test matrix (nepreskakovat)

Unit a integration testy musia pokryt:

• Happy path: create -> fund -> deliver -> release
• Unauthorized call scenare
• Pokus o dvojite vykonanie instrukcii
• Deadline edge scenare
• Fee rounding pri malych sumach
• Pokusy o token account mismatch

Ak testy neskusaju “ukradnut” funds, su nekompletne.

8. Rollout plan

Pragmaticky rollout:

1. interny beta pilot s nizkymi limitmi,
2. mainnet cohorta s allowlist sellerov,
3. automaticke alerty na failed releases a stuck escrows,
4. postupne navysovanie limitov.

Beri to ako payment infrastrukturu. Rollout disciplina je dolezitejsia ako rychle pridavanie funkcii.

9. Preco je to silny prvy Solana produkt

Escrow dava okamzitu biznis hodnotu:

• trust vrstva pre marketplace transakcie,
• nizsia operacna rezia na reconciliation,
• jasna cesta k platform fee.

A technicky to pripravi tim na tazsie veci:

• account design,
• signer/authority bezpecnost,
• deterministicke state machine,
• produkcny monitoring on-chain flow.

Finalny zaver

Ak chces seriozny Solana use-case, postav escrow skor nez spekulativne mechaniky.

Dostanes uzitocny produkt, realny transakcny objem a codebase, na ktorom vies stavat pokrocilejsie programy.