Compare app patterns.
Use the first sections to see what Bitcoin, Ethereum, Solana, stablecoins, TRON, Hyperliquid, and oracle networks taught.
Application layer
Build from Kaspa's actual edge.
The app question is not which chain to copy. It is where fast mined ordering, UTXO state, self-custody, covenants, proof hooks, and later verifiable programs can make a product meaningfully different.
Read by goal
This page has four jobs.
Find Kaspa-shaped ideas.
Skip to the native filter, live lane, Toccata lane, and execution order before designing anything.
Keep layers separate.
Use the Toccata, vProgs, RTD, and now/later sections to separate primitives from app-level semantics.
Check what is not live.
Use the status wording and sources before repeating any claim about native DeFi, DAGKnight, vProgs, or oracle-style apps.
Application thesis
Build where Kaspa is different, not where another chain already won.
The application case for Kaspa is not "copy Ethereum, add speed." It is a Proof-of-Work money layer that wants to stay lean while giving builders shared ordering, fast inclusion, UTXO discipline, covenants, verification hooks, and eventually native-feeling verifiable programs. The point is to let finance and coordination grow around the monetary base without making every L1 node execute every app.
That changes the app lens. A good Kaspa app should ask: does this need self-custodied money, credible ordering, fast PoW sampling, local UTXO state, covenant rules, proof-backed execution, or synchronous composition later? If not, it may just be a normal web app or a better fit for an existing VM ecosystem.
Why applications matter
Tokens are valued for access to a useful system, not only for slogans.
A crypto asset can be valuable because it is money-like, because users need it for block space, because it secures a network, because apps create fee demand, because it coordinates participants, or because markets believe those things may become larger later. The weak version is pure narrative. The strong version is a network where useful activity keeps needing the asset or the infrastructure.
This is why application layers matter. Bitcoin's strongest application is scarce, self-custodied, censorship-resistant money. Ethereum's strongest application layer is programmable shared state: stablecoins, DeFi, NFTs, DAOs, rollups, and settlement for other systems. Solana's application layer is fast consumer-style UX: trading, wallets, mobile apps, memecoin markets, payments experiments, DePIN, and social or game-like flows. TRON became important because cheap stablecoin transfer is a real user job. Hyperliquid shows that an app-specific chain can win by doing one product extremely well. Stablecoins are valuable because they made dollar settlement programmable and global.
Kaspa should be judged the same way: what unique applications become natural when the base layer is fast mined settlement, UTXO state, high-frequency Proof-of-Work sampling, and future verification-oriented programmability?
What other networks taught
Killer use cases usually match the chain's design advantage.
| Network lane | Unique selling point | Applications it helped create | Lesson for Kaspa |
|---|---|---|---|
| Bitcoin | Scarce PoW money, high settlement conservatism, simple rules. | Self-custody, long-horizon savings, collateral, treasury asset, Lightning payments, settlement reference. | Do not underrate the monetary application. PoW culture can itself be the app. |
| Ethereum | General programmable shared state and composability. | Uniswap, Aave, Maker/Sky, Curve, ENS, OpenSea, Farcaster, DAOs, rollup settlement, stablecoin DeFi. | Apps compound when developers can combine assets, rules, identity, and markets. |
| Solana | Fast UX and low-cost state changes. | Jupiter, Kamino, Drift, Jito, Phantom, Magic Eden, Tensor, Pump.fun, BONK, DRiP, Solana Pay, Blinks, Helium, Hivemapper, Render. | UX changes what people try. Fast settlement has to show up in products, not just diagrams. |
| Stablecoins | Programmable dollars, global availability, 24/7 transfer. | USDT/USDC payments, remittances, exchange settlement, payroll, savings access, merchant flows, DeFi collateral. | Users adopt boring utility when it beats the old rail on access, speed, or cost. |
| TRON | Cheap high-volume transfer for stablecoins. | TRC-20 USDT transfer, JustLend DAO, SUN.io, exchange and payment flows. | One narrow utility can become huge if it is cheaper and easier than alternatives. |
| XRPL / XRP | Fast low-cost payments, native DEX, issued assets, payment channels. | Xaman, XRPL DEX tools, tokenization, NFTs, cross-currency payments, payment-channel micropayments. | Payment-specific primitives matter; not every chain wins by becoming a general app VM. |
| BNB Chain | Retail distribution, low fees, exchange-linked ecosystem, opBNB, Greenfield. | PancakeSwap, Venus, games, AI/social apps, RWA experiments, storage/data apps, high-volume retail DeFi. | Distribution and cheap transactions can bootstrap usage, but quality varies heavily. |
| Dogecoin / meme lane | Simple transfer plus culture, humor, liquidity, and community identity. | Tipping, payments experiments, social coordination, attention markets, exchange liquidity. | Culture is a real adoption vector, but it is weak if it never becomes useful behavior. |
| Chainlink / oracle lane | External data and cross-system messaging for smart contracts. | Price feeds, proof-of-reserve, automation, cross-chain workflows, risk data. | Apps often need real-world inputs, but oracle trust has to be explicit. |
| Polygon / prediction markets | Low-cost EVM-compatible app deployment and consumer distribution. | Polymarket-style prediction markets, gaming, NFTs, brand programs, app experiments. | Prediction and coordination markets need cheap interaction, clear resolution, and credible rules. |
| Hyperliquid / app chain lane | A chain optimized around one product: high-performance on-chain trading. | Perpetuals, spot markets, on-chain order books, trader APIs, app-specific liquidity. | The winning app may need custom constraints, not a generic "anything app" story. |
Pattern library
The examples matter because they reveal repeatable app patterns.
DeFi primitives
Uniswap, Aave, Curve, Maker/Sky, Jupiter, Kamino, Drift, PancakeSwap, Venus, and Hyperliquid show the recurring stack: swaps, lending, collateral, derivatives, stable assets, liquidity routing, and risk engines.
Wallet gateways
MetaMask, Phantom, Xaman, and exchange-linked wallets show that the first killer app is often the interface that makes everything else reachable.
Token launch and attention markets
Pump.fun, BONK, meme assets, launchpads, NFT mints, and social trading show that cheap creation plus liquidity can create huge activity, even when quality is uneven.
Stablecoin settlement
USDT on TRON, USDC across major chains, and exchange settlement flows show that boring transfer utility can drive real network demand.
Real-world infrastructure
Helium, Hivemapper, Render, io.net-style compute, and RWA experiments show how tokens can coordinate hardware, data collection, or capital formation.
Prediction and coordination
Polymarket-style markets, assurance contracts, DAOs, grants, and public-goods funding show where crypto is not just finance but credible multi-party commitment.
Example shortcut
Large networks won by doing different jobs.
The full coin comparison belongs on the coin and tradeoff pages. For app design, the useful shortcut is simpler: Bitcoin proved money, Ethereum proved programmable shared state, Solana raised UX expectations, stablecoins proved boring settlement demand, Hyperliquid proved focused app-chain execution, and oracle networks proved external data is a separate trust problem.
Kaspa's native question
Do not copy Ethereum or Solana; build around real-time Proof of Work.
Kaspa's application layer should not start with "how do we recreate every Ethereum app?" It should start with the properties that are actually different: fast Proof-of-Work inclusion, a UTXO model, GHOSTDAG ordering of parallel work, low-latency settlement feel, and a roadmap aimed at covenants, ZK verification, sequencing commitments, and app-level verifiable programs.
The right filter is simple: if an application does not care about credible ordering, censorship resistance, self-custody, open participation, adversarial coordination, or real-time settlement, it may be better as a normal database or on a chain that already has the exact app ecosystem it needs.
Kaspa should shine where a fast, mined, neutral settlement layer changes the product itself.
Community advantage
A fair-launched coin can turn a large community into builders.
Kaspa's fair-launch culture matters because the application layer does not have to be handed down by one company. A broad community can build wallets, dashboards, market tools, education, payment flows, covenant examples, vaults, coordination markets, and later vProg applications around the same base asset.
Modern coding tools make that more practical. A motivated community member can use agents like Codex to prototype interfaces, write docs, test small apps, build analytics, translate ideas, or create developer examples without waiting for a centralized product team. That does not remove the need for audits, legal review, security discipline, or primary-source status checks, but it lowers the cost of turning good ideas into working experiments.
This can also be a non-financial way to earn and accumulate KAS: build useful things, serve users, create infrastructure, win grants, charge for real products, or contribute to businesses that need Kaspa rails. That is not investment advice, legal advice, or a promise that any app will succeed. It is the practical point of an open network: people can build value around it instead of only talking about price.
Translate, do not clone
How those patterns could become Kaspa-native.
| Pattern elsewhere | Kaspa-native version | Why it fits Kaspa | Status lane |
|---|---|---|---|
| MetaMask / Phantom / Xaman | A wallet that explains inclusion, confirmation confidence, UTXO control, vault policy, and app permissions in plain language. | Kaspa's first app layer needs users to understand fast PoW risk states, not just balances. | Live foundation now; richer policies post-Toccata |
| TRON USDT transfer | Fast self-custodied settlement for merchants, remittances, tips, payroll batches, and exchange flows. | Kaspa already has fast PoW settlement feel; the missing work is product UX, liquidity, and integrations. | Live foundation now |
| Uniswap / Jupiter | Simple swaps and liquidity routing after asset and covenant primitives mature. | Market apps need credible fast ordering, but native DeFi should wait for the right foundations. | Post-Toccata / vProgs |
| Aave / Maker / Kamino | Collateral vaults, guarded lending, stable assets, and risk-managed liquidity with explicit liquidation and oracle assumptions. | Fast settlement and UTXO vault policy could be useful, but risk engines need mature programmability. | vProgs / roadmap |
| Hyperliquid | A Kaspa-settled market app optimized for one job: auctions, collateralized perps, hashpower markets, or real-time liquidity. | The lesson is focus: build a product that uses Kaspa's ordering and settlement edge, not a generic app portal. | vProgs / app-specific architecture |
| Polymarket | Prediction and assurance markets for events, public goods, research bounties, software funding, and coordination problems. | Stag-hunt problems are directly aligned with credible commitment and RTD coordination framing. | Toccata for simple contracts; research for deeper oracle markets |
| Helium / Hivemapper / Render | Proof-of-service or proof-of-resource markets for bandwidth, compute, sensing, local infrastructure, or AI-agent work. | Kaspa's high-frequency PoW and coordination-market research may be useful for real-time attestations later. | Research / architecture |
| ENS / Farcaster / social graphs | Identity, handles, reputation, access passes, and portable group membership tied to self-custody. | The first useful versions may be simple access and membership systems, not a full social network. | Post-Toccata / vProgs |
| Pump.fun / meme launchpads | Safer launch and bonding tools with clearer risk labels, anti-scam defaults, and transparent liquidity paths. | Attention markets will happen if creation is cheap; the design question is whether they can be less extractive. | Post-Toccata opportunity |
Live lane
What can be useful on Kaspa before Toccata.
Fast PoW payments
Wallets, merchant flows, tips, remittances, and exchange withdrawal UX that make confirmation confidence understandable instead of just saying "fast."
Self-custody tools
Safer wallets, address books, payment requests, invoicing, accounting exports, and recovery education for users who want direct control.
Miner and node dashboards
Infrastructure that makes mining distribution, node health, propagation, fees, pruning, and network conditions visible to normal users.
PoW-native settlement UX
Point-of-sale and exchange flows that show inclusion, confirmation confidence, and risk level as separate states.
Education and proof tools
Visualizers, local node guides, blockDAG explainers, and verifiable references that make Kaspa's current system legible.
Real activity measurement
Dashboards that separate user payments, mining behavior, exchange movement, spam, fees, and app tests instead of treating all transactions equally.
Toccata lane
Toccata could make UTXO applications practical, but it is not live yet.
Toccata is the near-term hard-fork track for covenants, Silverscript, ZK verification foundations, sequencing commitments, and vProgs groundwork. The site should treat it as targeted, not live, until primary activation evidence changes that status.
| Opportunity | What it could look like | Why Kaspa may fit | Status |
|---|---|---|---|
| Vaults and wallet policies | Time-locked spending paths, delayed withdrawals, emergency keys, spending limits, and business treasury controls. | UTXO covenants can express constrained asset movement without turning every account into a global VM object. | Post-Toccata opportunity |
| Assurance contracts | Funds move only if enough participants commit by a deadline; otherwise they return. | This maps directly to stag-hunt and public-goods coordination: the rule is credible before everyone acts. | Post-Toccata opportunity |
| Conditional escrow | Milestone payments, disputes, deposits, delivery windows, and refund paths governed by transparent script rules. | Fast settlement helps escrow feel usable while covenants keep the state machine constrained. | Post-Toccata opportunity |
| Native assets and access passes | Tickets, memberships, credentials, game items, loyalty points, and redeemable claims with clear custody rules. | Some assets need fast transfer and self-custody more than full general-purpose DeFi at first. | Post-Toccata opportunity |
| Atomic market primitives | Simple swaps, auctions, batch settlement, OTC flows, and intent-style exchange with bounded script behavior. | Kaspa's edge is credible fast ordering; market design should use that rather than pretending mature DeFi is already here. | Post-Toccata opportunity |
| Games and state machines | Chess-like or turn-based apps where state is carried through constrained UTXO transitions. | The useful point is state discipline, not the game itself: registration, player state, game state, move routing, and final settlement. | Post-Toccata opportunity |
Toccata vs vProgs
Toccata is the foundation. vProgs are the fuller app architecture.
These should not be described as competing chains, rival clients, or two separate versions of Kaspa programmability. Toccata is the nearer L1 hard-fork track: covenants, covenant IDs, ZK-facing verification work, sequencing commitments, native-asset groundwork, and developer tooling. vProgs are the longer app architecture: proof-producing programs that use Kaspa for shared sequencing, commitments, verification, and eventually synchronous composability.
The design philosophy is neutral primitives first. Kaspa should not decide which oracle, prediction market, portfolio app, DePIN market, launchpad, or trading strategy is "the" app. It should expose durable L1 surfaces; applications define the incentives, semantics, data sources, legal limits, and user experience.
| Layer | What it is for | What not to claim yet | Status wording |
|---|---|---|---|
| Toccata / Covenants++ | Bounded UTXO programmability, covenant state machines, zk verification hooks, sequencing commitments, simple assets, vaults, escrow, and standalone based-zk experiments. | Do not call it live mainnet functionality until activation evidence exists. Do not claim it already gives full synchronous DeFi. | Targeted hard-fork track / TN12-style testing context |
| vProgs | A flat verifiable-program space where app logic can run off-chain, prove results, share Kaspa L1 sequencing, and aim for synchronous composition without ordinary rollup islands. | Do not flatten it into a generic L2, or imply the runtime is production-ready just because the prototype repo is public. | Roadmap architecture / early prototype implementation |
| Attestation markets | App-defined internet-money flows where opt-in miners or rewarded reporters are paid to expose external-event signals under explicit rules. | Do not describe the app logic as protocol-prescribed. Kaspa provides primitives; apps provide incentives, encoding, sources, and risk models. | App-layer construction over primitives |
What becomes possible
The practical split is L1 covenants, standalone based apps, then full vProgs.
The thesis is not "launch many independent L2s." It is closer to: keep Kaspa L1 as the neutral ordering, data, settlement, and verification anchor; let applications add their own semantics and incentives directly against those primitives; and avoid separate app empires with their own sequencers when L1 can provide the shared sequence.
| Stage | What builders can target | What remains later |
|---|---|---|
| Payload / based-VM experiments | VMs or app interpreters can read data posted to Kaspa L1 and follow the L1 order. This is useful for experiments, games, demos, and less trust-critical activity. | Without ZK settlement, L1 does not verify the app state. Trustless KAS bridging, canonical state commitments, and mature composability are missing. |
| Toccata L1 covenants | Peer-to-peer covenant systems, vault policy, escrow, assurance contracts, native assets, covenant state machines, and bounded local UTXO flows through Silverscript and script-engine extensions. | Not a global Ethereum-style VM where every node executes every app's state. |
| Standalone based-zk apps | Apps that follow Kaspa L1 sequencing, prove execution, use L1 settlement/canonical bridge patterns, and can be built by core or external teams as vProgs-compatible based computation. | They communicate through L1 proof/bridge paths first, not full synchronous composition between every program. |
| Hans' vProgs runtime work | An early Rust framework for based computation on Kaspa: scheduler, resource access, batch execution, rollback, storage/state layers, node VM, L1 bridge, and ZK proving pipeline. | The repo itself says early development/prototype; APIs and architecture can change. |
| Full vProgs direction | A one-dimensional program space with shared Kaspa sequencing, computational-DAG metadata, prover-backed execution, and synchronous composition without rollup-island fragmentation. | This is the later architecture target, not the immediate Toccata app surface. |
vProgs lane
vProgs point toward richer apps without making L1 execute everything.
vProgs should be framed as app-level verifiable programs or ZKVM-style environments around Kaspa, not ordinary rollups and not live mature app rails. The important design direction is L1 as sequencing, commitments, verification, and metadata while richer app logic runs in proof-producing environments.
Michael Sutton's vProgs framing adds an important design target: a one-dimensional space of programs that share Kaspa L1 as the sequencer, so apps can synchronously compose without being trapped in separate rollup islands. The L1 should know sequencing, commitments, dependencies, and enough metadata to regulate computational scope, while provers handle execution and validity proofs.
Recent covenant++ notes describe a staged path: inline zk covenants, based zk covenants, canonical bridges, native-asset bridge work, and eventually more efficient sequencing commitments where proving cost can follow a specific vProg's activity instead of the entire DAG. That is roadmap architecture, not live app infrastructure.
Native-feeling DeFi
Lending, liquidity, stable assets, swaps, options, and collateral systems that feel cohesive while keeping proof and sequencing constraints explicit.
Shared liquidity apps
App lanes that can coordinate around common assets and commitments without fragmenting every market into isolated islands.
Proof-backed credit markets
Markets where collateral, position state, liquidation rules, or reputation proofs can be verified without trusting a central app server.
Private-but-auditable workflows
ZK systems where users prove eligibility, solvency, compliance facts, or game outcomes without exposing every underlying detail.
AI-agent commitments
Agents that can post commitments, escrow funds, buy services, coordinate with each other, and settle outcomes through verifiable rules.
Composable public goods
Funding, matching, insurance, and maintenance markets where the hard part is credible multi-party commitment, not just payment transfer.
RTD and coordination
Kaspa's weirdest opportunity is coordination, not another token casino.
Hashdag's RTD and Staghunt framing point to a more unusual application lane: markets and institutions where people need credible commitment before they act. These are the places where a normal website can collect promises, but the participants still worry that the operator can censor, reorder, change terms, or disappear.
Yonatan Sompolinsky's Tokenize London example makes the idea concrete. A liquidity provider could define a strategy for an external event, such as an index ruling that affects market positioning. An internet-money layer would read the relevant sources, miners could opt in to attest to the event, and the system would sample the Proof-of-Work majority quickly enough to act in the same flow.
At 10 BPS this can be illustrated, but the confidence from a one-second sample is still not the final RTD vision. The stronger claim appears with much higher sampling density, DAGKnight-style adaptive latency, and 100 BPS-type ambitions, where an attestation can be finalized within roughly one internet round trip. Even then, the event source, incentives, anti-MEV design, scheduler, dispute process, and implementation details remain hard problems.
Public-goods assurance
Projects, research, events, software, or local infrastructure that only unlock funding once enough participants join under fixed rules.
Real-time auctions
Fast, open auctions for scarce digital goods, access, blockspace-related rights, or services where ordering and censorship resistance matter.
Oracle-backed markets
Prediction, insurance, and settlement markets that need external data, but where oracle trust, incentives, and dispute paths are explicit.
First-to-know signal markets
Watch miners or other rewarded reporters begin attesting to an event, then surface the earliest credible signal before normal feeds agree.
Machine-to-machine settlement
Agents, devices, miners, apps, and services buying resources or making commitments at internet speed with self-custodied funds.
Now / later boundary
The internet-money flow needs several pieces that are not all live.
| Capability | What it enables | Status |
|---|---|---|
| 10 BPS GHOSTDAG settlement | Fast inclusion, fast PoW user experience, wallets, payments, infrastructure, and clearer confirmation UX. | Live |
| Attestation-capable primitives | Opt-in event reporting, early external-event signals, oracle experiments, and first-to-know dashboards built by apps. | App-level design over primitives |
| MEV-aware ordering or auctions | Protects users who delegate an if-this-then-that strategy from miners or searchers exploiting the same event signal first. | Research / design work |
| Toccata covenants and ZK hooks | Vaults, assurance contracts, state-machine apps, simple assets, bridge foundations, and zk covenant experiments. | Targeted hard-fork track, not live until activated |
| STARK-sized proof support | Large validity proofs on Kaspa, with block-size and standard-fee tradeoffs to avoid cheap spam. | TN12 context / mainnet design question |
| vProgs | Native-feeling apps, shared sequencing, synchronous composability, unified liquidity, and prover-backed execution. | Roadmap architecture |
| DAGKnight / higher BPS RTD | Denser real-time majority sampling and more robust internet-round-trip attestation finalization. | Research / future upgrade direction |
Short list
The most interesting Kaspa apps would make coordination feel real-time.
Assurance markets
Funds unlock only when enough people commit by a deadline. This is the cleanest public-goods and stag-hunt fit.
Prediction and event markets
Useful only with explicit oracle, reporter, dispute, and legal assumptions. Fast settlement does not remove those hard parts.
First-to-know terminals
Apps could reward fast attestations and surface early confidence changes before normal feeds agree.
Merchant escrow and vaults
Live payment UX can improve now; covenant policies could later add refunds, limits, delays, and recovery paths.
Hashpower and service auctions
PoW culture and fast ordering fit markets for scarce technical resources, proofs, compute, data, and app-specific services.
AI-agent commitments
Agents need small, machine-readable commitments: deposits, task payment, completion proofs, and dispute rules.
Builder filter
Good Kaspa app ideas should pass this test.
- Needs credible shared state. The app gets meaningfully better when no single operator controls the record.
- Benefits from fast mined settlement. Real-time Proof-of-Work feel changes user experience, risk, or coordination.
- Uses UTXO constraints well. The app can be modeled as bounded state transitions, vaults, commitments, assets, or settlement flows.
- Does not require fake real-world truth. If the app depends on off-chain facts, it names the oracle and dispute assumptions clearly.
- Can start narrow. The first version solves one concrete problem before claiming to replace finance, identity, games, or law.
Execution order
The practical plan is primitives first, apps second, ecosystems third.
| Phase | Build focus | What success looks like |
|---|---|---|
| Now | Wallets, payment UX, infrastructure, explorers, mining/node visibility, education, confirmation-risk tools. | People can use and understand the live network without trusting one interface. |
| Toccata | Covenant examples, vaults, simple assets, escrow, assurance contracts, UTXO state-machine demos, STARK/zk proof experiments, developer docs. | Builders can make small useful apps without claiming full DeFi is live. |
| vProgs | Proof-producing apps, shared sequencing, richer market logic, native-feeling DeFi, private proofs, app-level composability, canonical bridge design. | Applications get Ethereum/Solana-level usefulness while preserving Kaspa's verification-oriented design. |
| Research | DAGKnight, 100 BPS sampling, RTD-derived attestations, oracle markets, MEV auctions, TangVM-style flows, coordination markets, AI-agent commitments. | The coordination thesis becomes concrete enough to test against real users and adversarial conditions. |
Sources
Use these as maps, not investment recommendations.
- CoinGecko market-cap pages for a current top-asset snapshot; rankings change and should not be treated as advice.
- Ethereum.org apps for Ethereum application categories and examples.
- Solana application guide and Solana DePIN page for Solana app categories and DePIN examples.
- XRPL.org for XRPL payment, DEX, token, and payment-channel primitives.
- BNB Chain DappBay rankings for BNB Chain dApp categories and examples.
- TRON developer docs for TRON's stablecoin and DeFi ecosystem framing.
- Kaspa: Mining the Internet at Tokenize London for Yonatan Sompolinsky's RTD, miner-attestation, internet-money flow, and focus/flywheel framing.
- KASmedia Hong Kong wrap-up for historical context on Michael Sutton's Crescendo/L1-L2 bridge talk, the ZK panel with Hans Moog, and the 2025 discussion around based rollups, state management, and liquidity fragmentation.
- Michael Sutton's vProgs masterclass for shared sequencing, one-dimensional program space, synchronous composability, computational DAGs, prover incentives, and sovereignty obligations.
- rusty-kaspa Toccata branch, rusty-kaspa TN12 branch, and kaspanet/vprogs for current implementation/prototype evidence. Treat branches as moving targets.
- KIP-21 pull request for partitioned sequencing commitments and O(activity) proving direction; confirm final status before calling it activated.
- Michael Sutton's covenant++ and vProgs milestone notes for inline zk covenants, based zk covenants, canonical bridge work, efficient sequencing commitments, and RTD context.
- Michael Sutton's STARK-sized blocks and min-fee notes for the STARK proof, block-size, standardness-fee, and elasticity tradeoffs.
- Kaspa Explained sources for the Kaspa status hierarchy and source discipline.