Public FAQOpen dApp

How It Works

Lifecycle, roles, and contract gates

FlashAlliance enforces a strict state machine. The frontend helps, but the contract itself is the final source of truth. If a wallet, deadline, approval, or state is wrong, the transaction must fail.

Funding

The alliance is raising ERC20 deposits and preparing one acquisition proposal.

  • Allowed: approve token, deposit, cancel failed funding, vote acquisition, reset expired acquisition, buy NFT.
  • Blocked: sale voting, emergency withdrawal, settlement claim.
  • Key checks: wallet must be a participant, deposit cannot exceed quota, target must be reached before buy.

Acquired

The alliance already owns the NFT and governance moves to exit management.

  • Allowed: vote sale, execute sale, vote emergency withdrawal, execute emergency withdrawal.
  • Blocked: new deposits and new acquisition funding flow.
  • Key checks: buyer approval for ERC20 payment, sale deadline, sale quorum, NFT still held by alliance.

Closed

The alliance lifecycle is finished.

  • Allowed: claim proceeds after sale, read history, inspect final balances.
  • Blocked: new funding, new NFT acquisition, new sale cycle.
  • Important: a new NFT requires a new alliance instance.

Role model

  • Participant: can fund, vote, execute buy or sale flows, claim proceeds, and interact with emergency logic when state allows it.
  • Owner/admin: the alliance owner is also a participant, but additionally controls pause and unpause.
  • Seller: not a participant by default. The seller only needs to approve one NFT for the alliance.
  • Buyer: not a participant by default. The buyer only needs to approve the ERC20 payment for the alliance.
  • Non-participant observer: can inspect data but cannot send governance or funding transactions.

What usually blocks execution

  • Wrong state: for example trying to deposit after NFT acquisition or trying to sell before the alliance actually owns the NFT.
  • Wrong wallet: participants can vote, but seller and buyer must connect their own wallets for approval steps.
  • Wrong token units: human-readable FATK amounts must be converted to token decimals before contract write calls.
  • Wrong proposal tuple: second and later votes must match the first proposal exactly, including deadline.
  • Missing approval: `buyNFT` needs NFT approval from seller; `executeSale` needs ERC20 approval from buyer.
  • Expired deadline: acquisition, sale, and emergency actions all have deadline-bound proposals.

Operational best practices

  1. Use one browser profile or one wallet window per role during local QA so participant, seller, and buyer contexts do not blur together.
  2. Always refresh the alliance page after major state transitions such as buy, sale execution, or claim.
  3. Use the generated seller and buyer approval pages instead of asking external actors to use console commands.
  4. Never reuse a closed alliance for the next NFT. Deploy a new one.