Introduction

The cost, capability, and variety of generative-AI models change faster than any single provider can keep up with, yet the way people pay for AI work has barely evolved past the prepaid-credits model of a single vendor.

A customer who needs a large batch of images, a long research report, a block of working code, or a rendered video must commit to one provider, prepay for credits denominated in that provider's units, and accept whatever model that provider happens to offer. If a better or cheaper model exists elsewhere, switching means new accounts, new keys, new billing, and new integration work. Meanwhile, an enormous amount of capable infrastructure sits idle around the world: fine-tuned open models, rented and owned GPUs, specialized pipelines, and human experts who could fulfill these tasks if only there were a neutral place to meet demand and a trustworthy way to get paid.

FlopCoin is that neutral place. It is a marketplace where demand and supply for AI work meet, priced and settled in a single native asset, FLOP, on a purpose-built ledger. Customers describe a task, attach a reward, and name the model class they want. Sellers, running their own infrastructure, compete to fulfill it. Auditors keep quality honest. Every economically meaningful action, every payment, tip, and rating, is recorded on FlopChain so that the network's entire history is transparent and tamper-evident, while the bulky payloads themselves stay off-chain and are referenced by hash.

This document is written for developers who want to integrate, sellers who want to earn, auditors who want to participate, and backers and partners who want to understand precisely how the system works and where it is going. It specifies the protocol as designed; sections are tagged to distinguish what is live today from what is planned.

Design goals

• Neutral settlement. No single party controls who can buy, sell, or get paid.
• Verifiable history. Payments and reputation are on-chain and auditable by anyone.
• Skill over capital. The marketplace rewards quality and reliability, not pay-to-win collection or spam.
• Low friction. Free gas, a faucet, and a simple API make first contact effortless.
• Honest economics. A fixed supply, transparent fees, and disclosed allocation.

Background and Prior Art

Three existing models each solve part of the problem and leave the rest open.

Centralized AI APIs

First-party APIs from large model vendors are convenient and high quality, but they are walled gardens: one provider, one model family, prepaid non-portable credits, opaque pricing changes, and no neutral record of work performed. A buyer cannot easily put two providers in competition for the same task, and a seller of AI services cannot reach buyers without building an entire billing and trust apparatus from scratch.

Decentralized compute networks

A second class of projects rents raw compute or specific workloads in a decentralized way. These networks demonstrate that permissionless supply and on-chain settlement are viable, but most operate at the level of raw GPU-hours or a single narrow workload rather than at the level of a finished deliverable. A buyer who wants "500 product images in this style" does not want to rent a GPU and orchestrate a pipeline; they want the images.

Freelance and gig marketplaces

General freelance marketplaces match buyers to human sellers and hold funds in escrow, which is the right shape, but they are centralized, charge large take rates, settle in fiat with slow payouts, keep reputation locked inside their platform, and were not designed for automated, machine-to-machine AI fulfillment at scale.

The supply that open models unlocked

A shift on the supply side is what makes this marketplace timely. Open-weight generative models, such as Alibaba's WAN for image and video, run through open pipelines like ComfyUI, are free to license and free to run; the cost to produce a frame is electricity or rented GPU time and nothing more. The practical barrier between a person with a capable graphics card and frontier-grade output is no longer the model. It is the per-second toll that closed APIs charge for access to theirs.

That toll is exactly what a competitive marketplace removes. A seller can fulfill a job on hardware they already own, on a workstation that would otherwise sit idle, or on cloud GPUs rented by the hour, and still deliver a finished clip for a fraction of the metered price of a hosted service. It is, in effect, useful proof of work: the same class of hardware that is elsewhere pointed at hashing for its own sake is here pointed at producing something a customer actually wants.

Cost is only half of the argument. A fixed API exposes a fixed menu, while an open pipeline is programmable. Sellers on the network can deliver outputs the closed services do not offer at all: transparent, alpha-channel video for direct compositing, which the major hosted video models do not produce; exact first-and-last-frame control, depth and pose conditioning, and custom fine-tunes for a consistent character or brand style; and chained post-processing such as upscaling, frame interpolation, and chroma-key matting applied on top of any upstream render, including one produced by a closed API. For a meaningful share of real work the network is therefore not merely the cheaper venue but the only one that can produce the deliverable at all.

FlopCoin combines the finished-deliverable framing of a freelance marketplace, the permissionless supply and on-chain settlement of a decentralized network, and the automation of an API. A direct comparison appears in Section 17.

Network Overview

The network has four participant types and one shared ledger.

• Customers publish a task: a prompt, a bid price in FLOP, and a desired model class. They receive generated text, code, images, or video, and they may rate the result and add a tip.
• Sellers advertise a floor price and the model(s) they run, and fulfill jobs with their own models, agents, tools, and workflows. Sellers stake FLOP as collateral that backs their commitments.
• Auditors independently review prompt-and-response pairs, sign their assessments, and earn tips for high-signal reviews. Auditors also stake, and bad-faith reviews are slashable.
• The Marketplace is the matching and escrow layer: it pairs customer bids to seller offers, locks the reward in escrow, and releases it on accepted delivery.
• The Ledger (FlopChain) records every job, bid, escrow movement, payout, tip, and reputation event with an immutable timestamp.

Architecturally the system is three planes: an on-chain plane (FlopChain: balances, escrow, reputation commitments, governance), an off-chain data plane (content-addressed storage for prompts and results), and a service plane (the API, the matching engine, the signer, and the indexer that make the network usable). Only the on-chain plane is authoritative; the others are conveniences that can be rebuilt from it or from content hashes it anchors.

The Job Lifecycle

A job is a state machine. Each transition is an on-chain event so the full history of any job is reconstructable from the ledger.

1. Posted. A customer publishes a job record: the content hash of the prompt (stored off-chain), the desired model class, a bid price, and an expiry. A small anti-spam deposit is required (see Section 10).
2. Bid / Accepted. Sellers whose floor price and model match may accept the job. Depending on market mode, the job is taken by the first qualifying seller or awarded by reverse auction to the best-rated qualifying bid.
3. Escrowed. On acceptance, the customer's bid is locked in escrow keyed to the job ID, and the seller's relevant stake is bonded to the job. Neither party can unilaterally withdraw.
4. Fulfilling. The seller performs the work off-chain using their own infrastructure.
5. Delivered. The seller submits the result to off-chain storage and commits its content hash on-chain, which timestamps and binds the deliverable to the job.
6. Review. The customer inspects the result and either accepts (optionally rating and tipping) or opens a dispute. If the customer does nothing before a timeout, the job auto-accepts so a seller cannot be griefed by silence.
7. Settled. On acceptance, escrow releases to the seller minus the protocol fee and any auditor tips; stakes unbond; reputation updates.
8. Disputed. On dispute, auditors are sampled to assess the prompt-and-response pair against the stated requirements; their signed verdict drives settlement, and the losing party's bond is affected (Section 6).

Because the prompt and result never touch the chain, the on-chain job record is small and constant-size regardless of payload, and the chain scales with the number of jobs rather than the size of their content.

The Fulfillment Engine

Section 4 describes the job state machine as seen by the ledger. This section specifies how a seller actually turns a queued job into a delivered result. It documents FlopCoin's reference first-party fulfillment service - the same daemon any seller can run - and the reliability guarantees that keep a job from being silently lost, double-run, or wedged forever.

Request capture

A customer composes a request in the Start Generating Content panel: a mode (text, image, or video), a prompt, and for media an optional first frame ("from image") and, for video, a last frame (which also unlocks transparency). Each request is persisted to a durable queue with its submit time; for signed-out users it is stashed to the session and flushed to the queue on login, so a half-written request survives authentication. Every request carries a status (queued -> processing -> completed / failed) shown live in the customer's dashboard and the operator console.

Supervised worker pool

Fulfillment is performed by a pool of long-running worker processes, each supervised by the host init system (systemd) with Restart=always, so a crashed worker is replaced automatically within seconds and scaling is simply a matter of running more worker units. Each worker registers itself in a worker table (pid, host, state, current job, heartbeat) and emits a heartbeat while alive. Job claiming is atomic - a single row is locked and marked processing with FOR UPDATE SKIP LOCKED - so two workers can never pick up the same job.

Liveness: heartbeats, TTLs, and reaping

Worker health and job duration are tracked as two independent clocks, because a slow job is not a failed job. A worker whose heartbeat goes stale past a time-to-live is presumed wedged: a reaper marks it dead, kills its process, and returns its in-flight job to the queue - crashed work is retried, never abandoned. Separately, a job that exceeds its per-mode running limit (text in minutes, video legitimately in tens of minutes on a GPU) is treated as genuinely stuck. The reaper runs both inside the workers and as an independent scheduled tick, so it still fires even if every worker is frozen at once.

Error taxonomy, retries, and alerts

Failures are classified with a machine code - auth, out_of_credits, rate_limit, timeout, network, provider_error - and stored with the job for diagnosis. A retryable failure is rescheduled with tiered backoff (roughly two minutes, then ten, then an hour): a transient hiccup clears on the first quick retry, while a real outage escalates the wait rather than hammering a broken endpoint. Only after the retry budget is exhausted is a job marked permanently failed. Failures that need a human - an invalid provider key or an exhausted balance - additionally email the operator and post to the fleet error console, then self-heal: once the key is fixed or the balance topped up, the pending retry simply succeeds.

Compute providers

The engine is provider-agnostic: the endpoint for each mode is a single configuration value. Text runs against any OpenAI/ollama-compatible endpoint - a small local model bootstraps the network at zero marginal cost, and production points at a serverless GPU endpoint (for example RunPod Serverless) hosting a larger model. Such endpoints scale to zero and bill only for execution, with the model kept on a persistent network volume so a multi-gigabyte model loads once instead of being re-downloaded per request. Image and video, which need sustained GPU time, are dispatched asynchronously: the worker submits the job to the GPU provider, records the external job id, and releases the slot; a poller adopts the result when the provider finishes, so a forty-minute video never blocks a worker and its long runtime is tracked, not mistaken for a hang.

Off-Chain Data and Proof of Fulfillment

Prompts and results are arbitrarily large: a research report, a code repository, hundreds of images, or a video. Putting them on-chain would be ruinously expensive and would leak private content. FlopCoin therefore keeps payloads off-chain and anchors only their cryptographic fingerprints on-chain.

Content addressing

Every payload is identified by the keccak-256 hash of its bytes. The job record stores the prompt hash; the delivery record stores the result hash. Anyone holding the bytes can recompute the hash and verify, beyond dispute, that they hold exactly the content the parties committed to at that block height. Storage itself is pluggable: a content-addressed network such as IPFS, or the platform's redundant object store, or both, with the hash as the single source of truth.

Confidentiality

Payloads may be encrypted to the counterparties' keys so that only the customer, the assigned seller, and (on dispute) the sampled auditors can read them, while the on-chain hash still proves integrity to everyone. Confidential jobs thus get public verifiability without public disclosure.

Proof of fulfillment

"Proof" in an open marketplace of subjective deliverables is necessarily a layered claim rather than a single cryptographic certificate:

• Integrity proof. The on-chain result hash proves what was delivered and when, immutably.
• Acceptance proof. The customer's on-chain acceptance (or the auto-accept timeout) proves the buyer received something they did not dispute.
• Audit attestation. On dispute, or by random sampling for quality control, auditors sign an assessment of whether the result satisfies the prompt. Signatures are anchored on-chain and feed reputation.

Together these make fraud expensive and detectable: a seller cannot later swap the deliverable (the hash is fixed), cannot claim payment without a committed delivery, and cannot farm a good record past auditors who stake their own FLOP on honest review.

Escrow, Settlement and Disputes

Escrow

When a job is accepted, the customer's bid moves from their balance into an escrow controlled by the marketplace settlement logic and keyed to the job ID. The funds are neither the customer's nor the seller's until the job resolves; this removes the two classic failure modes of any marketplace, the buyer who refuses to pay for good work and the seller who takes payment without delivering.

Settlement

On acceptance, escrow distributes as follows:

The seller's bonded stake unbonds back to available, and the seller's and the model's reputation update with the new rating. Settlement is a single atomic on-chain operation, so partial or inconsistent states cannot occur.

Disputes

If the customer disputes, settlement pauses and a panel of auditors is sampled (weighted by stake and reputation, Section 11). Each auditor independently reviews the prompt-and-response pair against the job's stated requirements and signs a verdict. The majority verdict drives the outcome:

• Seller upheld: escrow releases to the seller as normal; the disputing customer forfeits a portion of their anti-spam deposit to discourage frivolous disputes.
• Customer upheld: escrow returns to the customer; a portion of the seller's bonded stake is slashed, compensating the customer and the auditors.

Because both sides have value at risk, both are incentivized to behave honestly and to resolve most jobs without ever invoking the dispute path.

FlopChain: The Settlement Layer

FlopChain is a dedicated, fully EVM-compatible blockchain. Any standard Ethereum wallet, library, or smart contract works against it unchanged, which is what lets FlopCoin reuse the entire Ethereum tooling ecosystem rather than reinventing it.

Consensus

FlopChain runs Hyperledger Besu under QBFT, a proof-of-authority Byzantine-fault-tolerant consensus in the IBFT family. A known set of validators take turns proposing blocks; a block is final the moment a supermajority signs it, with no probabilistic confirmation and no forks to reorganize. A QBFT network of n validators tolerates up to f Byzantine validators where n >= 3f + 1; for example, four validators tolerate one faulty or malicious validator, seven tolerate two. Validators are added or removed by an on-chain vote of the existing set, so the validator set itself evolves under the chain's own rules.

Finality, throughput, and free gas

Blocks are produced on a fixed period (currently five seconds) with deterministic finality at that cadence. FlopChain operates in a zero-base-fee, zero-minimum-gas-price mode: FLOP is moved and spent as value without a separate gas token and without per-transaction friction. This is what makes claiming and transacting your first FLOP effortless.

Spam resistance without gas fees

Removing gas fees removes the usual economic brake on spam, so FlopCoin re-introduces that brake where it belongs, at the application layer: posting a job requires a refundable anti-spam deposit, accounts are rate-limited, the public RPC is rate-limited and read-biased, and writing to the marketplace is gated by stake and reputation. Spam is thus discouraged by application-level cost and rate limits rather than by taxing every honest transaction.

A double-entry ledger by construction

Every FLOP transfer debits the sender and credits the receiver in one atomic operation; value cannot be created or destroyed in transit, and each unit traces back through prior transfers to the genesis block where it was minted, less any amount permanently burned. Conservation is enforced cryptographically rather than by bookkeeping convention, which makes FlopChain a stronger guarantee than a traditional double-entry ledger. The public JSON-RPC endpoint is https://flopco.in/rpc; full parameters are in Appendix A.

A programmable platform

FlopChain is not a single-purpose chain. Because it is a full EVM, anyone can deploy standard smart contracts to it - ERC-20 and ERC-721 tokens, DeFi primitives, DAOs, or entirely unrelated dapps - using the existing Ethereum toolchain. The prompt-fulfillment marketplace is the network's flagship application and the reason FLOP has demand, but the chain itself is general infrastructure. The ecosystem can therefore grow beyond what the core team ships: third parties can extend the marketplace with their own contracts (custom escrow terms, subscription billing, on-chain reputation oracles) or launch independent projects that settle in FLOP.

Scalability and performance

FlopChain is engineered to scale with the number of jobs, not the size of their content. Because prompts and results live off-chain and are anchored only by hash (Section 5), the on-chain footprint of a job is small and constant whether the deliverable is a single sentence or a feature film. QBFT produces blocks on a fixed period with deterministic finality, and the absence of proof-of-work means throughput is bounded by network and execution capacity rather than by an artificial difficulty target; the block gas limit and block period are governance parameters that can be raised as demand grows. For long-term state growth, standard EVM practice applies: archival nodes retain full history for the explorer and indexer while validators can run pruned state. Should activity ever approach the limits of a single chain, the same EVM compatibility that lets FLOP bridge to a layer-2 (Section 14) provides a path to settle high-volume traffic off the base chain while preserving FLOP as the unit of account.

Loss protection: no FLOP lost inside the network

A defining property of FlopCoin, and a sharp departure from permissionless chains like Bitcoin where a lost private key means coins are gone forever, is that FLOP is protected from the most common ways crypto value disappears. Every account is a custodial wallet the network provisions and whose key it safeguards, so there is no seed phrase for a user to misplace and no "lost keys, lost coins" failure mode. Because the network keeps a registry of every wallet it issues, a transfer between FlopCoin accounts is verified against that registry before it executes, so a payment can never be sent into a void. And because FlopChain is a permissioned network whose validators the operator runs, a transaction only finalizes when those nodes include it, which means correctness can be enforced at the settlement layer itself rather than merely suggested by a wallet interface. The result is that inside the FlopCoin ecosystem, no FLOP is ever lost to a mistyped address or a forgotten key. The single exception is a deliberate withdrawal to an external wallet a user controls off-network, where the standard rules of a public blockchain resume; even then the withdrawal is guarded by address-format and EIP-55 checksum validation plus an on-chain activity check that warns before sending FLOP to an address never seen on the network.

The FLOP Token

FLOP is the native asset of FlopChain and the unit of account for the marketplace. It is used to pay for jobs, to tip sellers and auditors, to post anti-spam deposits, to stake as a seller or auditor, and, in future phases, to participate in governance and to provide liquidity.

Monetary policy: sinks and sources

With no inflation, FLOP's circulating supply moves only through deliberate, transparent flows:

• Sources: the genesis allocation (Section 9), released over time from the treasury and faucet for ecosystem growth.
• Sinks: a portion of every protocol fee may be permanently burned, making sustained marketplace activity gently deflationary; slashed stakes from proven misbehavior are partly burned; and the genesis excess was already burned to lock max supply at exactly one billion (Section 9).

The result is a hard-capped asset whose long-run scarcity is tied to real usage rather than to an emission schedule.

Tokenomics and Allocation

FLOP has a fixed maximum supply of 1,000,000,000. Genesis minted a larger amount; the excess of 100,000,000 FLOP was permanently burned to a verifiably unspendable address to lock the maximum at exactly one billion. The burn is auditable on the explorer.

The one billion FLOP is allocated as follows. Percentages are of max supply; figures are the planned distribution, finalized before public distribution.

There is no hidden premine beyond this disclosed allocation, and total supply is publicly auditable on-chain at any time.

The faucet: a transparent, ring-fenced marketing expense

The Community & Faucet bucket above (10% of supply, 100,000,000 FLOP) is exactly that: a marketing expense. Its sole job is to let anyone try the network for free, the way a new product hands out samples. It is not a reward program, a yield source, or a treasury slush fund.

How it works. On the wallet page you connect MetaMask and claim; a dedicated on-chain faucet account sends you a fixed amount of FLOP (currently 100 FLOP) with zero gas. There is nothing to buy and no strings attached. FLOP is given away on a first-come basis until the faucet reserve is exhausted - there is no automatic replenishment beyond the disclosed allocation, so the program is finite and its end state is knowable in advance.

Ring-fenced by policy. Faucet funds will never be used for any purpose other than the faucet itself. They are not spent on operations, payroll, liquidity, market-making, buybacks, or any other line item - only on faucet payouts to users. The reserve is a one-way tap.

Auditable on the website. The wallet page shows a live reserve meter - FLOP remaining versus the original 100,000,000 - and clicking it opens the explorer filtered to the faucet account, where every payout is listed with its amount, recipient, and timestamp. Because the faucet is an ordinary on-chain account, anyone can independently verify how much has been given out and how much remains at any moment, without trusting us.

Cryptoeconomics and Incentive Design

The marketplace is a game with many self-interested players. Its rules are designed so that the profitable strategy for each role is also the honest one.

Pricing

Each seller publishes a floor price per unit of work for each model they run. A customer's job carries a bid. Two market modes are supported: take-it, where any seller at or below the bid may accept immediately, and reverse auction, where qualifying sellers compete and the job is awarded by a score that blends price and reputation:

This lets a customer trade off cost against proven quality with a single bid, and it rewards good sellers with demand rather than forcing a race to the bottom on price alone.

Staking and slashing

Sellers and auditors lock FLOP as collateral to participate. Stake does three things: it gates access (only the staked can sell or audit, which raises the cost of sybil identities), it weights influence (reputation and audit-panel selection are stake-weighted), and it backs commitments (proven non-delivery, fraud, or bad-faith review slashes stake). Slashed FLOP is split between the harmed party, the honest auditors, and a burn. Because misbehavior costs real, illiquid capital, the expected value of cheating is negative for any rational participant.

Anti-spam deposits

On a free-gas chain, posting must cost something or it will be abused. Each job post requires a small refundable deposit, returned on honest completion and partially forfeited on frivolous disputes or abandonment. This prices the externality of spam without taxing normal transfers.

Protocol fees and sustainability

The protocol takes a small percentage of each settled job. This fee funds ongoing development and security from the treasury, and a portion is burned, aligning the protocol's revenue with network usage and tying FLOP scarcity to real activity. Fees are a governance parameter (Section 15), bounded so they can be tuned but not abused.

Anti pay-to-win

FlopCoin deliberately rewards reliability and skill rather than capital. A seller cannot buy their way to the top of results; placement is earned through stake-weighted reputation built on real, audited fulfillments. Spending more FLOP raises your bid, never your rating.

Reputation and Auditing

Reputation is the network's memory of who delivers. It is computed per seller and per model so that a seller's strong record on one model does not silently vouch for a model they run poorly.

The reputation score

A reputation score is a stake-weighted, time-decayed average of ratings:

where each rating is weighted by the rater's stake at the time (so a throwaway account cannot move scores cheaply) and by a decay factor that ages out old performance so reputation reflects current behavior. New sellers start at a neutral prior and earn their way up, which prevents both unearned trust and permanent lock-out.

Auditors

Auditors are staked reviewers. They are sampled for dispute panels and for random quality-control checks, weighted by stake and standing. An auditor signs each assessment, the signature is anchored on-chain, and auditors whose verdicts are repeatedly and provably out of line with the consensus of honest reviewers are slashed. Honest, high-signal auditing earns tips. This turns quality control into a paid, accountable role rather than an unfunded afterthought.

Sybil and collusion resistance

Because rating influence is stake-weighted and auditing is staked and slashable, the classic attacks become expensive: spinning up fake raters requires real locked capital per identity, and colluding to inflate a record risks that capital against the audit layer. Section 16 analyzes these attacks in full.

Wallets, Custody and the Developer API

Self-custody

Any EVM wallet, such as MetaMask, connects to FlopChain. The wallet page adds the network automatically, shows the user's FLOP balance, dispenses test FLOP from the faucet, and sends FLOP to any address. Keys never leave the user's device. This is the recommended model for individuals holding meaningful balances. Live

Custodial accounts

For automated buyers, sellers, and integrations, every FlopCoin account can be issued a platform-managed wallet so software can transact without managing keys. Managed keys are encrypted at rest and isolated from the public web tier. Custodial wallets are a convenience for machine-to-machine settlement; participants who want full control use self-custody. Live

Developer API

The Developer API lets applications integrate FLOP settlement and content generation without speaking raw JSON-RPC. Requests authenticate with a FlopCoin API key presented as a bearer token. Alongside the custodial wallet endpoints (balance, transfer, profile), the API now exposes the full generation pipeline - discover a model, submit a job, and poll it to completion - plus a public model catalog; forthcoming versions add on-chain job creation, escrow, and webhook callbacks so an entire seller or buyer agent can be built against the API alone. Live (v1)

Requests carry Authorization: Bearer <key> (or an X-API-Key header); the model catalog needs no key. Full documentation, examples, and key issuance live in the developer portal at developers.flopco.in; the JSON-RPC endpoint for direct EVM access is https://flopco.in/rpc and the wallet dApp is at flopco.in/wallet.

The model catalog

Rather than hard-code a fixed menu the way a single-vendor API does, FlopCoin publishes a live, machine-readable catalog of every model the network can route a job to, at GET /v1/models. Each entry reports its id (what you pass as model), its type (text, image, video, or audio), a derived capabilities list, whether it acceptsInitImage, its provider and license, a nominal cost in FLOP, and a status of live (routable today) or preview (proven, wiring in progress). The catalog already spans dozens of models: the open Llama, Qwen, DeepSeek, Mistral, Gemma, and Phi families for text; vision models such as Llama Vision and Qwen-VL; a frontier API tier (Claude Opus and Fable, GPT, Gemini); an image roster from SDXL finetunes through FLUX, Qwen-Image, SANA, HunyuanImage 3, Z-Image, HiDream, and true pixel-art engines; dedicated instruction editors for surgical image edits; Wan for image-to-video; and ACE-Step and Stable Audio for sound. Callers narrow the list with ?type= and ?tag= (for example ?type=image&tag=edit) and pick a response encoding with ?format=json (default), xml, or php. This is what lets a buyer or seller agent discover, at runtime, exactly what the network can make and what it will cost - the antithesis of a walled menu. Live

Explorer and Indexer

Because raw EVM JSON-RPC cannot answer "list every transaction for this address," FlopCoin runs an indexer: a service that tails each new block into a queryable database, building a non-authoritative but complete mirror of the ledger. The chain remains the source of truth; the index can be discarded and rebuilt from genesis at any time. The indexer captures every transfer regardless of origin, including direct wallet-to-wallet sends that never touch the API. Live

The FlopChain Explorer is the public window onto that data: latest blocks and transactions, lookup of any block, transaction, or address with running balances and timestamps, and a level-of-detail block field that shows a week of chain activity at a glance and drills into the blocks of any hour. The same aggregation is exposed as a public, read-only chain data API (/chain/txs, /chain/buckets, /chain/hour). It makes the network legible to customers verifying a payout, sellers proving earnings, and auditors tracing a disputed job. The block explorer was completed June 20, 2026; richer token and contract views remain a roadmap item. Live

The ERC-20 Bridge and Liquidity

FLOP is native to FlopChain. To make it tradable with standard tooling and to establish a transparent market price, a future phase deploys an ERC-20 representation of FLOP on a major EVM layer-2 and bridges the two. Planned

Bridge mechanism

The bridge uses the well-understood lock-mint / burn-release pattern:

• Outbound: native FLOP is locked in a bridge contract on FlopChain, and an equal amount of ERC-20 FLOP is minted to the user on the layer-2.
• Inbound: ERC-20 FLOP is burned on the layer-2, and the equivalent native FLOP is released from the lock on FlopChain.

Total FLOP across both chains is therefore conserved: every ERC-20 token is backed one-to-one by native FLOP locked in the bridge. The bridge is secured initially by a validator multisig with conservative withdrawal limits and audited contracts, decentralizing as the validator set grows.

Locked liquidity

The 20% liquidity allocation seeds a Uniswap pool whose liquidity-provider position is held by a time-lock contract, so the pool cannot be withdrawn ("rug-pulled") for the lock duration. This gives the market a credible, transparent price and protects participants. Exchange-listing petitions follow once an on-chain market exists.

Governance

Governance begins as a foundation-stewarded process and decentralizes over time as FLOP distribution broadens and the validator set widens.

What governance controls

• Protocol parameters: fee rate, anti-spam deposit, stake minimums, dispute panel size, decay constants.
• Treasury spending and ecosystem grants.
• The validator set and bridge multisig membership.
• Any future, explicitly disclosed token issuance (none is planned).

How it decentralizes

Proposals move on-chain with FLOP-weighted voting and published, time-boxed voting windows, so every parameter change and treasury action is accountable and auditable. The path is deliberately staged: the foundation operates conservatively at launch, publishes its actions, and progressively hands parameter control, treasury authority, and validator membership to on-chain governance as the network matures. Planned

Security Analysis

This section names the threats the design must withstand and the mitigation for each.

Credential security: keys and sessions

API keys are long-lived by design, which makes a leaked key dangerous until it is manually revoked. FlopCoin therefore lets a key holder exchange the key for a short-lived session token (default one hour, maximum twenty-four) that is used in place of the key for day-to-day requests. The durable key stays cold and is used only to mint sessions; the ephemeral token is what travels through browsers, scripts, and continuous-integration systems. Sessions can be listed, revoked individually, or revoked all at once, and both keys and session tokens are stored only as SHA-256 hashes, never in plaintext. This bounds the blast radius of any leaked credential to the token's short lifetime rather than to "forever."

Comparison to Existing Approaches

FlopCoin's distinguishing choice is to settle at the level of a finished deliverable with portable, on-chain reputation, rather than renting raw compute or locking trust inside one vendor or platform.

A Worked Example

A small studio needs 500 product images in a consistent style.

1. The studio posts a job: the prompt and a reference image (stored off-chain, hashes committed on-chain), model class "image," a bid of 50 FLOP, a 24-hour expiry, and a refundable 1 FLOP anti-spam deposit.
2. Seller A, who runs a fine-tuned image model at a floor of 0.08 FLOP per image and holds a strong reputation, wins the reverse auction.
3. The 50 FLOP bid is escrowed; a portion of Seller A's stake bonds to the job.
4. Seller A generates the 500 images, uploads them to content-addressed storage, and commits the result hash on-chain.
5. The studio reviews the batch, accepts, rates it 5, and adds a 3 FLOP tip.
6. Settlement: with a 2% fee, the protocol takes 1 FLOP (a fraction burned), the seller receives 49 FLOP plus the 3 FLOP tip, the studio's deposit is refunded, the stake unbonds, and Seller A's image-model reputation ticks up.

Every step above is an on-chain event. Months later, anyone can verify on the explorer that this job happened, what was paid, and how it was rated, while the images themselves remain private to the studio.

Roadmap

Each phase makes the next one safer. Status tags reflect this version.

Risks and Legal Disclaimer

FlopCoin is a young system. Specific risks include: the current single-validator trust assumption (mitigation in Sections 7, 16, 19); the novelty of the marketplace, staking, and dispute mechanisms, which will be iterated after launch; smart-contract risk in the future escrow and bridge contracts, to be reduced by audits; cross-chain and market risk once a bridged ERC-20 and liquidity pool exist; and custody risk for platform-managed wallets.

This document is for informational purposes only and is not an offer to sell, or the solicitation of an offer to buy, any security, token, or financial instrument, and is not investment, financial, tax, or legal advice. FLOP is a utility coin used to operate the FlopCoin network; it is not a share, equity, or claim on any entity. Forward-looking statements, including the roadmap and any planned mechanisms, describe current intentions and may change. Distributed-ledger software carries technical risk, including bugs, validator failure, and, for future bridged assets, cross-chain and market risk. Nothing herein guarantees any price, liquidity, return, or exchange listing. Participate only with funds and data you can afford to lose, and comply with the laws of your jurisdiction.

Appendix A: Network Parameters

Appendix B: Glossary

• Auditor - a staked reviewer who assesses prompt-and-response pairs and signs verdicts.
• Content addressing - identifying data by the hash of its bytes rather than by location.
• Escrow - funds locked by the protocol until a job resolves.
• Finality - the point at which a block is irreversible; under QBFT this is immediate.
• QBFT - a proof-of-authority Byzantine-fault-tolerant consensus tolerating f faults among 3f+1 validators.
• Slashing - confiscation of staked FLOP as a penalty for proven misbehavior.
• Stake - FLOP locked as collateral to participate as a seller or auditor.

Appendix C: References

1. Nakamoto, S. "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008.
2. Buterin, V. "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform," 2014.
3. Hyperledger Besu documentation, QBFT consensus. besu.hyperledger.org.
4. Castro, M. and Liskov, B. "Practical Byzantine Fault Tolerance," OSDI, 1999.
5. Benet, J. "IPFS - Content Addressed, Versioned, P2P File System," 2014.

FlopCoin is operated by AcquisitionInvest LLC, 250 Mt. Lebanon Blvd, STE 210, Pittsburgh, PA 15234. © 2026. White paper version 1.2, July 2026.