# MeterCall L4 Whitepaper **Version 1.0 — April 21, 2026** **Author: Yoshi (pseudonymous)** **Network: Base (Layer 2), L4 Aggregation Layer** **Token: PCP — 1,000,000,000 fixed supply, zero inflation** --- ## Abstract MeterCall L4 is an aggregation and routing layer that sits above existing L1s, L2s, and L3s. Its purpose is narrow and stubborn: let anyone, anywhere, call any of 20 million+ Web2 APIs and 30+ blockchains through a single call, and let the person closest to the work get paid for routing it. The little guy with a Raspberry Pi in a bedroom beats the data center because he is closer, cheaper, and not trying to win everything. This paper explains how the routing works, how we keep the rich from capturing it, how PCP aligns the whole thing, and what we still don't know. --- ## 1. The Problem I Lived I ran nodes. I ran a lot of nodes. And the people with data centers won every time. It didn't matter that I showed up early. It didn't matter that I cared about the protocol. It didn't matter that my box had ninety-nine-point-something uptime. Once the economics turned, the people with capital bought bigger machines, put them in colocation, bought fatter pipes with better peering, hired somebody to tune their systemd units, and ate the rewards. The protocol said "decentralized." The reality was a small number of very well-capitalized operators, clustered in three or four ASNs, running most of the network. That is not decentralization. That is a shell with rich-guy insides. The pattern repeats on every chain I've touched: - **Block production concentrates.** Two or three pools, then two or three validators, then two or three stakers behind the validators. The Nakamoto coefficient trends to a number you can count on one hand. - **RPC concentrates.** Everyone ends up calling the same handful of node providers, and when one of them goes down the "decentralized" app goes down. The RPC layer is a single point of failure we pretend isn't one. - **Data centers eat the edge.** Anything that rewards uptime and bandwidth gets swallowed by whoever can write the biggest check to AWS or Hetzner. The moment you put "more bandwidth = more rewards" into a protocol, you've written a handout to capital. - **The little guy pays the fees and never earns them.** Fees flow up. Rewards flow up harder. By year two, the people who believed the whitepaper are subsidizing the people who showed up with a checkbook. - **MEV gets extracted by the most-connected.** Colocation with the sequencer wins. Geographic latency is a moat that capital buys. The honest version of most "decentralized" networks is a few dozen operators who can't afford to leave because their hardware is sunk cost, and the rest of us paying for the privilege of saying we participated. I participated. I did not get paid. This paper is about building a network where Joe Schmoe with a Raspberry Pi in Tulsa actually beats the data center in Ashburn — because he's closer to the request and the protocol rewards him for it. Not metaphorically. Mathematically. The cost function says so. The dilution curve says so. The hard cap says so. If we get the economics right, the little guy wins because the math is on his side for the first time. --- ## 2. Why Previous L1s, L2s, and L3s Didn't Fix It **L1s** (Ethereum, Solana, Cosmos): honest attempt at base-layer decentralization. Validator sets still concentrate — staking pools, lending markets, liquid-staking derivatives, and stake-weighted protocols create gravity wells that capital flows into. Fees and MEV concentrate harder because the most-connected actor always wins the auction. None of them were designed for calling Web2. The API world lives outside the chain entirely, and the bridge back in is either an oracle (centralized) or an off-chain computation (trust-you-bro). **L2s** (rollups, optimistic and ZK): cheaper execution. Great engineering. They still need sequencers. Sequencers are centralized today by design, decentralized "later." We have been told "later" for four years. Fraud-proof mechanics do not help a user who wanted to call an API; they help a user who wanted to move tokens. Still don't touch Web2. **L3s** (app-chains, appchains on L2s): cheaper app-specific execution. Great for games, onchain orderbooks, niche DeFi primitives. The tooling is getting good. What L3s don't solve is "I want to call the Stripe API and pay with crypto from a chain that isn't Ethereum, and I want the result in under 400 milliseconds, and I want to not trust a single bridge signer." That's not an L3 problem. That's a routing problem. **DePIN** (DIMO, Helium, Render): closer in spirit. Real hardware in real places. The economic design, though, still ends up rewarding capital concentration — big fleets beat small ones, and the protocols have a hard time writing a math-based anti-concentration curve that survives contact with lobbyists. None of these layers compete on **where the request is served from**. They compete on block production, execution correctness, and data availability. The actual bottleneck for real-world usage — the 50ms to 400ms of network latency between a user and the data that answers their question — is treated as somebody else's problem. "Put a CDN in front of it" is the standard answer. A CDN is not decentralized. A CDN is three companies. MeterCall L4 treats that latency as the whole problem. --- ## 3. Architecture MeterCall L4 is four components bolted together: a scheduler that chooses the best node for each call, a gossip layer that keeps nodes aware of one another, a settlement path that posts receipts and fees to Base, and a bridge mesh that moves calls across chains. None of these components are novel in isolation. The novelty — if there is any — is in how they fit together and in the economic curves that pin them to small operators. ### 3.1 What L4 actually is L4 is an aggregation and routing overlay. It does not produce blocks. It does not settle state. It sits on top of Base (L2 Ethereum) for settlement, receipts, and dispute resolution, and it routes calls between any caller and any of three pools of endpoints: 1. **Web2 APIs** — 20M+ indexed endpoints. REST, GraphQL, gRPC, WebSocket. 2. **Blockchains** — 30+ chains via native RPC + a bridge signer mesh. 3. **Builder modules** — programs deployed by creators that compose the first two. Every call is priced, metered, and billed per-invocation. x402 for payment-required responses. EIP-712 for signed routing receipts. The design constraint is that any call, regardless of endpoint class, should be indistinguishable to the caller from any other. "Get me the balance of this address on Solana" and "get me the current Stripe invoice total" look like the same API surface: a request with a budget and an expected response schema. The scheduler does not care which class the request is. It cares about which node can serve it cheapest, closest, and cleanest. ### 3.2 Geo-routing: why Joe Schmoe wins For a call from client `c` to endpoint `e`, the scheduler picks the node `n` that minimizes expected total cost: ``` cost(n, c, e) = α · rtt(n, c) + β · rtt(n, e) + γ · price(n) - δ · reputation(n) - ε · residential_bonus(n) + ζ · concentration_penalty(n) ``` Default coefficients (governance-tunable): `α=1.0, β=1.0, γ=0.6, δ=0.8, ε=0.4, ζ=1.2` `rtt` is round-trip-time in ms. `price` is the node's posted PCP-per-call. `reputation` is a rolling success-weighted score. `residential_bonus` is +20% scheduling weight for non-datacenter ASNs. `concentration_penalty` scales quadratically with how many other active nodes share the node's ASN and geohash-5 cell. A residential node in Tulsa serving a Tulsa caller, at the same price as an Ashburn datacenter node serving the same Tulsa caller, wins on α, ε, and ζ. It is not a handicap. It is the protocol acknowledging that proximity is real work. ``` scheduler decision (simplified) ----------------------------------- caller(Tulsa) ----> [ candidate set ] | +-- node A: Tulsa residential, ASN 7018, price 1.0 +-- node B: Ashburn datacenter, ASN 16509, price 0.9 +-- node C: Dallas datacenter, ASN 16509, price 0.95 +-- node D: Tulsa residential, ASN 22773, price 1.05 | v score(A) = 12 <-- lowest, wins score(B) = 18 score(C) = 17 score(D) = 13 ``` ### 3.3 Gossip layer Nodes gossip three things and nothing else: `(node_id, advertised_endpoints, price)`, `(call_id, receipt_hash)`, and `(node_id, heartbeat)`. Gossip is epidemic with fanout 6, TTL 4 hops. Anything larger than a receipt hash does not belong in gossip — it belongs in a direct fetch or on-chain. ``` gossip fanout (one epoch, fanout=6, TTL=4) ------------------------------------------- A ---> B C D E F G | B ---> H I J K L M | H ---> N O P Q R S ... (TTL=1, stops here) ``` ### 3.4 Anti-oligarch dilution curve The thing that kills every "decentralized" network is: one entity accumulates nodes until they dominate. We fight this at two layers — hard and soft. **Hard cap.** No single operator (proven by stake signature) can earn from more than 50 nodes in a 1,000-node network window. Excess nodes stay online but earn zero. **Soft curve.** Effective reward weight per node decays as a function of ASN and geohash-5 concentration: ``` weight(n) = base(n) · (1 / (1 + k · asn_share(n)^2)) · (1 / (1 + k · geo_share(n)^2)) ``` with `k = 4` by default. A node in an ASN that already holds 20% of active nodes has its weight multiplied by `1 / (1 + 4·0.04) = 0.862`. At 50% ASN share, `1 / (1 + 4·0.25) = 0.5`. At 80% ASN share, `0.28`. ``` dilution curve (ASN share -> weight multiplier, k=4) ---------------------------------------------------- 1.00 |*****.. 0.90 | ****. 0.80 | ***. 0.70 | **. 0.60 | **. 0.50 | **. 0.40 | **. 0.30 | ***. 0.20 | ****... 0.10 | ********* 0.00 +------------------------------------------> 0% 20% 40% 60% 80% 100% ASN share ``` The curve is continuous, so there's no cliff to game. A small operator with a unique ASN always beats a big operator adding their Nth redundant box. ### 3.5 Bridge mesh Cross-chain calls route through a bridge-signer mesh. Signers are a rotating committee of the top-reputation nodes, weighted by dilution curve (so the committee cannot ossify into one ASN). Bridge receipts are EIP-712 signed, posted to Base for dispute, and optimistically finalized after a 20-minute challenge window. Committee rotation is epoch-based, one epoch per 12 hours. Each epoch, the top 21 reputation-weighted nodes are selected subject to two constraints: no more than 4 committee members may share an ASN, and no more than 3 may share a geohash-3 cell. A 2/3 signing threshold is required to produce a valid bridge attestation. Conflicting attestations from the same committee member in the same epoch are slashable — both the conflicting receipt and the stake that backed it. ``` bridge signer committee (one epoch, 21 seats) --------------------------------------------- ASN AS7018 [*][*][*][*] 4 max ASN AS16509 [*][*][*][*] 4 max ASN AS3320 [*][*][*] ASN AS22773 [*][*][*] ASN AS8075 [*][*] ASN AS14061 [*] ASN AS13335 [*] ASN AS21859 [*] ASN AS6939 [*] ---------- 21 seats, 2/3 threshold = 14 signatures ``` ### 3.6 Call lifecycle End to end, a single call looks like this: ``` caller scheduler node endpoint ------ --------- ---- -------- | request + budget | | | |------------------->| | | | | scored select | | | | (cost fn) | | | |-------------------->| | | | | fetch/compute | | | |------------------->| | | |<-------------------| | | | EIP-712 receipt | |<---------------------------------------- | | | signed result + receipt hash | | | | | | x402 settle (PCP) | | |- - - - - - - - - - - - - - - - - - - - >| (on Base) | | | | 30% burn, split | ``` Settlement is optimistic. If the receipt hash does not match a deterministic re-fetch, any observer can submit a dispute within the challenge window and burn the node's stake. --- ## 4. PCP Tokenomics PCP is the unit of account, the fee token, and the governance token. Fixed supply, zero inflation, deflationary by use. ### 4.1 Supply - **Total supply:** 1,000,000,000 PCP - **Inflation:** zero, ever - **Burn:** 30% of every PCP-denominated fee is burned on settlement ### 4.2 Allocation ``` +-------------------------------+---------+---------------+-----------------------------+ | Bucket | % | Tokens | Terms | +-------------------------------+---------+---------------+-----------------------------+ | Team | 10% | 100,000,000 | 4-yr vest, 1-yr cliff | | Community / Airdrop (combined)| 30% | 300,000,000 | Launch + ongoing seasons | | Treasury | 20% | 200,000,000 | DAO-controlled multisig | | Launch liquidity | 20% | 200,000,000 | Paired on Base, locked 2 yr | | Ecosystem grants | 15% | 150,000,000 | Milestone-based, DAO-voted | | Strategic | 5% | 50,000,000 | 2-yr vest, 6-mo cliff | +-------------------------------+---------+---------------+-----------------------------+ | TOTAL | 100% | 1,000,000,000 | | +-------------------------------+---------+---------------+-----------------------------+ ``` ### 4.3 Burn mechanics Every call settles in PCP (or in another asset converted to PCP at the settlement oracle). 30% of the PCP-denominated fee is burned. 70% is split: - 60% to the serving node - 25% to the module creator (if a builder module was invoked) - 10% to treasury - 5% to the bridge-signer committee (if cross-chain) If no builder module is invoked, the creator 25% rolls to the node. ### 4.4 Staking curve Nodes must post `S` PCP as stake to be eligible for routing. `S_min` launches at 10,000 PCP per node. Stake is slashable for provable misbehavior (failed-receipt disputes, signed conflicting bridge attestations, downtime beyond SLA). Routing weight scales as: ``` routing_weight(n) = dilution_weight(n) · sqrt(stake(n) / S_min) ``` `sqrt` not linear — so a whale posting 100x stake gets 10x weight, not 100x. Combined with the dilution curve, this makes accumulation genuinely expensive. This is intentional. Linear stake-weighting is how every network we looked at ended up captured by the top 10 wallets. The sqrt curve flattens the top and rewards the middle. ``` staking curve (stake / S_min -> weight multiplier) -------------------------------------------------- 10 | ***** 9 | ***** 8 | **** 7 | *** 6 | *** 5 | *** 4 | *** 3 | *** 2 | **** 1 | ********* 0 +----------------------------------------> 1x 10x 25x 50x 75x 100x stake / S_min ``` ### 4.5 Delegation Holders who do not run hardware can delegate PCP to a node. Delegated stake counts in the sqrt curve, subject to a per-node ceiling: no node can have more than 20x S_min in total stake. This caps the top-end weight any single node can acquire (sqrt(20) ≈ 4.47x) and prevents delegation cartels from routing all calls to one operator. Delegators receive a pro-rata share of the node's earnings minus a commission the node posts publicly. Delegators share in slashing proportionally. There is no "delegator insurance." If the node misbehaves, you pay with the node. ### 4.6 Treasury and grants The 20% treasury is held by a DAO-controlled multisig. Initial signers are the team, a reputable legal trustee, and two community elects. Within 12 months, the team signature is removed and replaced with a second community elect. Treasury can fund grants, cover auditor retainers, seed liquidity, or burn additional PCP on governance vote. 15% ecosystem grants sit in a separate, milestone-release structure: builders receive tranches as they hit pre-declared, verifiable milestones. --- ## 5. Economic Security ### 5.1 Cost of attack Assume an attacker wants to corner 51% of routing weight. - Baseline: 1,000 active nodes, each staking `S_min = 10,000 PCP`. - Attacker must field at least 500 effective-weight-equivalent nodes. - Hard cap: max 50 nodes per proven operator. - So attacker needs **≥ 10 distinct operator identities**, each with 50 nodes. - Dilution curve: if all 500 are in the same ASN, their effective weight is multiplied by `1/(1 + 4·0.5²) = 0.5`. To offset, they need to double their stake per node. Total stake required: 500 nodes × 10,000 PCP × 2 (dilution offset) × (some premium for sqrt curve to reach 51% weight) ≈ **~25M PCP locked**, plus the operational cost of spinning 500 nodes across 10+ ASNs in 10+ geohash-5 cells. At a conservative $0.10/PCP launch price, that's ~$2.5M in locked stake exposed to slashing, plus infra. Corner case, not a target. ### 5.2 Sybil resistance - **ASN/geohash penalty:** makes splitting one rack into 50 fake nodes pointless. The concentration penalty is quadratic, so even small concentrations hurt, and large ones are crushed. - **Residential bonus gated:** the +20% bonus requires proof-of-residential-ASN, verified by a reverse DNS + ASN classification check + periodic active probing from diverse vantage points to detect VPS-behind-proxy patterns. The probe fleet rotates. Vantage points come from other nodes in the network, not a central prober. Fakeable in the short run, expensive in the long run. - **Stake lockup:** 14-day unbond. A Sybil that gets caught cannot yank stake and vanish. - **Receipt disputes:** any caller can challenge a receipt within a 20-minute challenge window and burn the node's stake on proof of mis-service. Proof is deterministic re-fetch matching — if the endpoint returns the same bytes in a later window, the node's receipt was fine; if not, the node served a wrong result and pays. - **Operator identity binding:** stake is posted from an identity key. Aggregating node rewards under one proven identity triggers the hard cap at 50. Trying to split identities means splitting stake, which means smaller sqrt-curve routing weight per node. The math cuts both ways. ### 5.3 What a sophisticated attacker actually has to do To corrupt a specific call: be selected by the scheduler, serve a wrong result, and hope no one re-fetches within 20 minutes. Expected value is negative unless the attacker can simultaneously suppress re-fetch, which requires dominating the watcher set. To corrupt a specific bridge transfer: get into the signer committee, produce a conflicting attestation, get caught, lose stake. Even a 50% committee takeover produces a challengeable attestation on-chain; the fraud window posts to Base. TVL caps limit the blast radius per bridge per epoch. To censor a caller: refuse to route. The scheduler treats unresponsive nodes as low-reputation. A caller who is censored by one node is served by another. Network-wide censorship requires network-wide collusion, which the dilution curve makes economically irrational to assemble. --- ### 5.4 Liveness MeterCall L4 does not produce blocks, so liveness is not a consensus question — it is a scheduler question. If a majority of nodes go offline, surviving nodes serve the load at higher prices. Callers set a max-budget per call; if no node meets the budget, the call fails and the caller's funds are returned. This is graceful degradation instead of chain halt. Scheduler state is replicated across watchers; no single scheduler instance is authoritative. A scheduler that misbehaves can be disregarded by nodes, which simply stop accepting its routes, and the network re-converges in seconds. ## 6. Roadmap **Q2 2026 (now — June):** - Monday April 21: L4 mainnet on Base, PCP TGE, 48 seed nodes live, 22 bridges, 30+ chains. - Open node registration with dilution curve enforced. - First airdrop season (caller + node operators in closed beta). **Q3 2026 (July — September):** - Community node wave: 1,000-node target. - Builder module marketplace v1 (creator 30% / platform 70% split on modules built on the platform). - Bridge-signer committee rotation live. - DAO governance contracts deployed; treasury handover. **Q4 2026 (October — December):** - Cross-L4 interop spec (other aggregation layers can peer). - Mobile node client (yes, phones; metered). - Second airdrop season keyed to actual usage, not wallet-sniping. - Full open-sourcing of scheduler reference implementation. --- **Beyond 2026:** - Full decentralization of the scheduler reference implementation into a P2P elected role. - Confidential computing enclave support for regulated endpoints (HIPAA, PCI) where the serving node must not see the payload. - Proof-of-serving ZK circuits replacing optimistic dispute windows for hot-path latency-sensitive calls. - Native integration with at least three additional settlement L2s for redundancy. ## 7. Risks and Open Questions I'm not going to pretend these are solved. 1. **Residential-ASN verification is imperfect.** Determined adversary with a VPS fleet behind residential proxies can fake it for a while. Our answer: active probing from diverse vantage points, plus economic cost of maintaining the fake. Not a proof. A cost curve. 2. **The dilution curve is a parameter, not a theorem.** `k=4` is a guess calibrated against simulated attacks. Governance can raise or lower it. It will probably need to move. 3. **Bridge-signer committees are still the weakest link in all of crypto.** We use rotation + dilution + slashing, but a well-funded attacker coordinating half the committee remains a tail risk. We cap single-bridge TVL in the contract until we have more data. 4. **L2 dependency.** Base could change fee markets, censor, or suffer outages. We target multi-L2 settlement (Base + Optimism + Arbitrum) in Q4 but we are not there yet. 5. **Regulatory.** PCP is a utility token within a functional network. That does not make it immune to regulators. The team is doxxed to counsel, not to the public. 6. **Scheduler gaming.** If nodes learn to predict the scheduler, they can game reputation. We rotate coefficients seasonally and keep some randomness in tie-breaking. Longer term, the scheduler itself will be decentralized into a P2P elected role so no single instance can be reverse-engineered against. 7. **Price volatility at TGE.** 20% launch liquidity is aggressive but not infinite. Expect volatility. PCP is a utility token. Do not buy it for price. 8. **Watcher quality.** Dispute relies on watchers re-fetching sampled calls. If watchers are lazy or captured, bad receipts slip through. We fund a baseline watcher fleet out of treasury through year one; watcher rewards come from slashed stake, not inflation. Steady-state watcher ratio is unknown — initial target is 1 watcher per 5 serving nodes. 9. **Endpoint flakiness.** A node serving a Web2 endpoint is at the mercy of that endpoint's uptime and rate limits. We de-rank nodes that return 5xx, but a legitimately-down endpoint can look like a failing node. The re-fetch dispute system partially mitigates — if the endpoint is down for everyone, nobody wins — but edge cases exist. Governance will iterate on scoring. 10. **Launch-day attention.** We are launching with 48 seed nodes. That is a small network. Early weeks will be volatile in performance and in price. We are telling you that now, in the whitepaper, rather than making excuses later. --- ## 8. How to Participate **Run a node.** Pull the container. Point it at your machine. Post 10,000 PCP stake. Declare which endpoints you will serve. Start earning per call. Residential connections get +20%. You don't need a datacenter. You don't need a static IP that costs $200 a month. You need a home connection, enough bandwidth to matter in your neighborhood, and the patience to let reputation build. Pi 5, mini-PC, old laptop in a closet — all fine. Docs: `/run-a-node.html`. **Stake.** Delegate PCP to nodes without running hardware. Read the node's uptime, reputation score, ASN concentration, and commission before you delegate. Your pick earns more if you pick a good node in a good location. Slashing applies proportionally — you share the downside, you share the upside. No "delegator insurance." Unbond in 14 days. **Build.** Deploy a module. A module is a signed program that composes calls — could be a compound API like "give me ERC20 transfers for this address across 5 chains" or "summarize the last 10 Stripe invoices." Creator earns 30% of every call to it. The module runs on MeterCall nodes, not on your laptop. Cover any domain — finance, geo, ML, scraping, whatever. Docs: `/agent-build.html`. **Govern.** Hold PCP. Vote on scheduler coefficients (`α`, `β`, `γ`, `δ`, `ε`, `ζ`, `k`), burn rate, grant allocations, bridge TVL caps, and signer committee size. Treasury is 200M PCP under multisig that the DAO controls. Proposals require a minimum PCP bond to prevent spam, refundable if the vote meets quorum. Every passed proposal has a 48-hour timelock before execution, so if something passes that looks like a capture attempt, holders have time to leave. **Watch.** Run a watcher node. Watchers don't route calls; they re-fetch random sampled endpoints and verify receipt hashes. If a serving node posts a receipt for a response that does not reproduce, the watcher files a dispute, burns the node's stake, and earns a bounty out of the slashed amount. Anyone can run a watcher. We think watchers are the most important role nobody talks about. --- ## Closing This is not a chain. This is a layer that makes every chain, and every API, reachable from one call, served by whoever is closest, owned by nobody who can big-time you. I lost to data centers once. I'm not losing again. Neither are you. — Yoshi April 21, 2026