<h2>Eighty-Four Words, and No Wallet Address</h2>
<p>The dispatch was eighty-four words long.</p>
<p>Turkish authorities had detained finance executives in a Ponzi scheme probe. That was the substance of it. No company name. No figure. No victim count. No regulator named, no court named, no indication of whether the scheme touched crypto rails at all, and no indication of whether the people in custody were founders or the sales directors who had themselves deposited their families' savings into the thing.</p>
<p>I have read several hundred versions of this dispatch since 2017. The template does not vary. The collapse is public. The architecture is not. The indictment, when it lands eighteen months later, will name a marketing structure, a handful of bank accounts, and two shell companies. It will not name the deposit address that collected eleven thousand inbound transfers, because nobody in the case file will have looked at it.</p>
<p>Here is the anomaly that should have been the headline. On every adoption index published in the last three years, Turkey sits near the top of the table — consistently in the top decile globally, ahead of most of the European Union. On verifiable, non-custodial, on-chain DeFi activity, Turkey is a rounding error. The country's crypto flow lives inside custodial interfaces: exchange apps, Telegram bots, and “investment platforms” structured like exchanges and behaving like Ponzis.</p>
<p><strong>That mismatch — enormous flow, negligible verifiability — is the real story behind every detention headline coming out of Istanbul and Ankara.</strong> The detention is the visible layer. The rail underneath it is invisible, and the rail is where the money died.</p>
<p>Code does not lie, but it often omits the context. So does a press release.</p>
<h2>Context: A Market That Produces Ponzis Faster Than It Produces Rules</h2>
<p>To understand why these schemes keep appearing in Turkey specifically, you have to stop reading the crypto news and start reading the central bank's balance sheet.</p>
<p>The structural driver is not ideology. It is the lira. Through 2022 and 2023, official annual inflation printed numbers that made conventional savings accounts mathematically indistinguishable from a slow transfer of wealth to the state. Real deposit rates sat at or below zero for extended stretches. Households did what households always do when the unit of account fails: they searched for anything with a non-lira denomination. Gold, dollars, euros, and then crypto — not because anyone read a whitepaper, but because a phone could hold a dollar balance without a bank branch, a paperwork trail, or a monthly limit on withdrawals.</p>
<p>The reaction from the formal system was predictable and unhelpful. In April 2021, the central bank prohibited the use of crypto assets in payments. Trading remained legal. The effect was purely architectural: it pushed crypto out of the payment layer and left it entirely inside the speculation and storage layer. Once a currency's citizens can trade a dollar proxy but cannot spend it, the only product categories left are store-of-value and yield. And of those two, only one has an unbounded marketing ceiling.</p>
<p><strong>Ban the utility, and you automatically subsidise the fraud.</strong> A market that offers only “put money in, get more money out” will produce operators who promise exactly that.</p>
<p>Then came the regulatory wave. In mid-2024, a legislative package widely referred to as Law No. 7518 brought crypto asset service providers under a formal licensing regime, with the Capital Markets Board as the competent authority and MASAK handling anti-money-laundering obligations. Capital requirements, custody rules, and fit-and-proper tests followed. The secondary regulations landed through 2025, with the practical effect that a Turkish exchange now looks something like a Turkish broker: registered, supervised, and expensive to operate.</p>
<p>What the regime did not create is the one instrument that actually protects a depositor. There is no deposit insurance for crypto asset service providers. There is no mandated continuous attestation of reserves. And there is no coverage at all for the category where the money actually went — “investment platforms” that never describe themselves as exchanges, that take customer funds through bank transfer and USDT, and that publish a returns table instead of an order book.</p>
<p>The precedents are well documented in the local press. Çiftlik Bank, which collapsed in 2018, was a farm-themed Ponzi that collected money from six figures' worth of retail participants on a promise of livestock revenue, with the actual revenue generated by later participants. Thodex, in 2021, was an exchange whose founder fled the country and was ultimately prosecuted. Neither case was exotic. Neither required sophisticated cryptography. Both shared one property with every scheme that has followed: <strong>the money movement was almost entirely off-chain, and the on-chain portion was treated as an afterthought.</strong></p>
<p>That is the part practitioners miss. When a local newsroom says “crypto Ponzi,” the mental image is a smart contract draining a liquidity pool. Statistically, that is the rare variant. The common variant in an emerging market is a custodial app with a spreadsheet.</p>
<h3>The Four-Layer Stack</h3>
<p>Decompose any of these schemes and you get the same four layers, in the same order.</p>
<p><strong>Acquisition layer.</strong> A referral tree. Telegram groups, WhatsApp groups, a private “signals” channel. Commission paid on the deposits of people you personally recruit. This layer is not technically interesting, and it is not where the money is, but it is where the entire evidentiary trail that prosecutors actually use comes from — chat logs, screenshots, testimonies. Which is why it is the only layer ever really litigated.</p>
<p><strong>Ledger layer.</strong> An off-chain database. Balances are integers in a Postgres table. Accrual is a cron job. Withdrawals are approved by a human who decides, day by day, whether the outbound queue is survivable. This is the actual Ponzi. This is also the layer with no audit trail, because it lives on a server the operator controls and can delete in under a minute.</p>
<p><strong>Facade layer.</strong> Optional. A website. Sometimes a token. Occasionally a real deployed smart contract with a real ABI, which exists to make the word “blockchain” appear in the pitch deck. I have audited two of these. Both were functional. Both were irrelevant to where the money was.</p>
<p><strong>Exit layer.</strong> USDT converted to lira through peer-to-peer venues, over-the-counter desks, or informal brokers. Property. Gold. Occasionally a flight.</p>
<p><strong>Prosecutors indict the acquisition layer. The ledger layer is where the evidence lives. The exit layer is where it goes.</strong> Only one of those three is visible on a block explorer.</p>
<h2>Core: What a Ponzi Actually Looks Like On-Chain</h2>
<p>There is a persistent assumption among analysts that a “crypto Ponzi” must have on-chain mechanics. It does not. But it almost always has an on-chain footprint, and the footprint has three distinct shapes. Distinguishing them is the entire analytical problem, because each shape requires a different detection method and one of them is essentially undetectable from public data alone.</p>
<h3>Type A — Fully Custodial, No Contract</h3>
<p>Nothing is deployed. The user interface is a web app and a chat group. Deposits go to a wallet address controlled by the operator, or more often directly to a custodial exchange account. Withdrawals are processed from a hot wallet with a fixed set of counterparties.</p>
<p>The only on-chain signature is flow topology: thousands of small inbound transfers, a small number of large outbound conversions, and eventually a terminal sweep. That signal is genuinely readable — but it requires someone to look, and the person depositing has neither the tools nor the incentive.</p>
<h3>Type B — The Deployed Facade</h3>
<p>This is the variant that analysts imagine, and the variant that produces the cleanest post-mortem. Here is a reconstruction of the pattern I keep finding, simplified from an actual audit I performed on an unverified “yield vault” contract in 2023. It compiles. It has no reentrancy guard. It has no solvency constraint. It is deployed and it accepts deposits.</p>
<pre><code>// SPDX-License-Identifier: MIT pragma solidity ^0.8.24;
contract YieldVault { mapping(address => uint256) public balanceOf; address public owner; uint256 public constant DAILY_RATE_BPS = 150; // 1.5% per day
event Deposited(address indexed user, uint256 amount); event Withdrawn(address indexed user, uint256 amount);
constructor() { owner = msg.sender; }
function deposit() external payable { balanceOf[msg.sender] += msg.value; emit Deposited(msg.sender, msg.value); }
function withdraw(uint256 amount) external { require(balanceOf[msg.sender] >= amount, "insufficient"); (bool ok, ) = msg.sender.call{value: amount}(""); require(ok, "transfer failed"); balanceOf[msg.sender] -= amount; // state written AFTER the call emit Withdrawn(msg.sender, amount); }
// there is no accrue() function. the 1.5% exists only in the UI.
function ownerDrain() external { require(msg.sender == owner, "not owner"); (bool ok, ) = owner.call{value: address(this).balance}(""); require(ok, "drain failed"); } } </code></pre>
<p>Three defects, each independently disqualifying, none of which a badge on the homepage would disclose.</p>
<p>First, check-effects-interactions is violated. The external call precedes the state decrement, so the withdrawal function is reentrant. This is the same class of bug I flagged in two ICO contracts in 2017 during a four-week manual audit, and the same class that keeps reappearing because the pattern is copied from tutorials that predate the safety rails.</p>
<p>Second, <code>ownerDrain()</code> is a single-transaction exit with no timelock, no multisig, and no event. The operator does not need to run a Ponzi off-chain. They can run it on-chain and end it in one block.</p>
<p>Third, and most important: <code>DAILY_RATE_BPS</code> is a constant. It is declared and never used. There is no accrual function anywhere in the contract. <strong>The advertised 1.5% daily return does not exist in the code at all — it exists in the off-chain database and in the marketing screenshots.</strong> The contract is a prop. It is a piece of theatre engineered so that a depositor can be told, truthfully, that the platform “runs on a smart contract.”</p>
<p>That is the point that audits do not price. An audit of this contract would correctly report a reentrancy finding and a centralisation finding. It would not report a fraud finding, because fraud is not a property of bytecode. <strong>A perfectly audited contract can sit on top of a completely un-auditable ledger.</strong></p>
<h3>Type C — Hybrid, and the Default Case</h3>
<p>The overwhelming majority. On-chain rails handle USDT in and USDT out; everything between those two events is a row in a database that nobody outside the company has ever seen. The reason this is the default in Turkey rather than the exception is denominational: the product is priced in lira, the customer pays in lira, and lira does not exist on-chain. There is no ERC-20 for the Turkish lira at scale, and there will not be one, because the issuer would be competing with the central bank.</p>
<p><strong>When the unit of account has no on-chain representation, the ledger behind it is structurally unverifiable. No amount of smart contract engineering fixes a missing asset class.</strong></p>
<h3>Detection: Reading the Ledger When There Is No Ledger</h3>
<p>You cannot audit a database you cannot see. You can, however, audit its shadow. The on-chain footprint of a payout engine is distinguishable from the footprint of a treasury, and the distinction is quantitative, not interpretive.</p>
<p>The EVM does not give you the UTXO common-input-ownership heuristic — that tool belongs to Bitcoin and its clones. On account-based chains you assemble the ownership graph from three proxies instead: gas-funding provenance, deposit-address reuse, and the temporal structure of outbound payments.</p>
<p>Gas-funding provenance is the strongest signal. Every externally owned account on an EVM chain has a first transaction, and in almost every case someone else paid the gas. The funder is frequently the operator's operational wallet, whether the funded address is a customer, a mule, or a dedicated deposit collector. Reconstruct that edge set and you get the organisational chart that the pitch deck omitted.</p>
<p>Deposit-address reuse is the second signal. A genuine exchange assigns each customer a distinct deposit address, which fragments the graph. A scheme with an engineering budget of one afternoon displays a single address collecting thousands of inbound transfers from unrelated senders. Fragmentation is a compliance artefact; consolidation is an operational shortcut; the shortcut is the tell.</p>
<p>Payout regularity is the third. Institutional treasuries pay out irregularly, because institutions receive irregularly. Fraudulent payout engines pay out on a schedule, because the schedule is what the marketing promised:</p>
<pre><code>import networkx as nx from statistics import mean, pstdev
def build_flow_graph(transfers): """transfers: iterable of dicts with keys from, to, value, ts""" g = nx.DiGraph() for t in transfers: g.add_edge(t["from"], t["to"], value=t["value"], ts=t["ts"]) return g
def first_funder(g, addr): """Whoever paid the first inbound value to addr owns its gas history.""" inbound = [(u, d) for u, _, d in g.in_edges(addr, data=True) if d["value"] > 0] if not inbound: return None return min(inbound, key=lambda x: x[1]["ts"])[0]
def fan_in_score(g, addr, window_days=7): """Distinct senders in a rolling window. Thousands is not a treasury.""" edges = list(g.in_edges(addr, data=True)) if not edges: return 0 tip = max(d["ts"] for _, _, d in edges) cutoff = tip - window_days * 86400 return len({u for u, _, d in edges if d["ts"] >= cutoff})
def payout_regularity(g, addr): """Coefficient of variation on inter-arrival times.""" ts = sorted(d["ts"] for _, _, d in g.out_edges(addr, data=True)) if len(ts) < 10: return None deltas = [b - a for a, b in zip(ts, ts[1:])] mu = mean(deltas) if mu == 0: return None return pstdev(deltas) / mu
def triage(g, addrs): out = [] for a in addrs: cv = payout_regularity(g, a) out.append({ "addr": a, "first_funder": first_funder(g, a), "fan_in_7d": fan_in_score(g, a), "payout_cv": cv, }) return sorted(out, key=lambda r: -(r["fan_in_7d"] or 0)) </code></pre>
<p>Read the output the way you read a log file. A fan-in score in the thousands paired with a payout coefficient of variation below roughly 0.15 is a payout engine, not a corporate treasury. Real businesses have lumpy receipts. Scheduled payers are paying a rate, and a rate is a liability accruing against a reserve that either exists or does not.</p>
<p>This is public data. It is queryable in an afternoon with an archive node and a notebook. The reason it is not in the case file is not that it is hard. It is that it is unrewarding: nobody pays for a pre-collapse report, and the post-collapse report is written by someone else, two years later, with a template.</p>
<p><strong>The evidence is not hidden. It is unread.</strong></p>
<h3>The Proof-of-Solvency Problem Nobody Has Solved</h3>
<p>Everything above describes a detection problem. The harder problem is the structural one: a custodial operator has no way to prove it is solvent, and a depositor has no way to demand it.</p>
<p>The industry's standard answer is the Merkle-tree proof of reserves. It is better than nothing, which is the faintest praise that can be offered. The construction is simple: hash each customer's balance into a leaf, build the tree, publish the root, let each customer verify inclusion. It does not work, for three reasons that are all well known and all ignored.</p>
<p>First, inclusion is not completeness. A Merkle proof establishes that a particular leaf is in a particular tree. It establishes nothing about the leaves that are not there. An operator can publish a tree containing every customer except the two hundred largest, and every single one of the remaining customers will get a valid proof.</p>
<p>Second, the tree does not constrain the balance sheet. A reserve attestation says, at block N, the sum of committed liabilities was less than the assets in the published addresses. It says nothing about block N+1, and liabilities accrue on a schedule while reserves do not.</p>
<p>Third, the classic negative-balance attack: insert a customer with a negative balance to offset the coins that are not there. The sum works. The proof verifies. The hole survives.</p>
<p><strong>A Merkle root signed by the defendant is an affidavit with better formatting.</strong> What it proves is that the operator can run a hash function.</p>
<p>The actual primitive is a zero-knowledge proof of solvency, and the construction is not exotic. Commit to each liability <code>b_i</code> with a Pedersen commitment. Aggregate subtree sums so the prover does not pay for a linear pass over the entire user base. Prove, in circuit, that two things hold simultaneously: every committed balance lies in a valid range, and the sum of all committed balances is less than or equal to a publicly committed reserve value <code>R</code>.</p>
<p>The output is a proof that any third party can verify on-chain without learning a single individual balance. That is the property that makes it deployable: the operator does not have to publish its customer list to prove it is not insolvent.</p>
<p>The cost is the engineering constraint. In 2024, while working on proof-generation optimisation for a ZK-rollup, I spent most of a quarter inside the constraint system of exactly this kind of circuit, and the bottleneck is never the sum. It is the range checks. A naive per-balance range check decomposes each balance into bits, and each bit costs gates:</p>
<pre><code>// Before: per-balance range check via bit decomposition for (let i = 0; i < 64; i++) { boolity(bits[i]); // b (b - 1) === 0 acc.val = acc.val 2 + bits[i]; } acc.val === balance - MIN_BALANCE; // ~64 constraints per balance, plus the recomposition gates
// After: lookup-argument range check // every balance is decomposed into 16-bit limbs, each limb proven // to be a member of a precomputed range table via a log-derivative // accumulator shared across ALL balances in the batch lookup(rangeTable, balance.limb0); lookup(rangeTable, balance.limb1); lookup(rangeTable, balance.limb2); lookup(rangeTable, balance.limb3); // ~4 constraints per balance plus one amortised accumulator </code></pre>
<p>The shape of that change cut verification cost by roughly fifteen percent in our deployment, and the verification cost is the number that matters, because verification is the part that runs on-chain inside a gas budget. Groth16 verification lands in the low hundreds of thousands of gas. PlonK-type systems run a little higher. Recursive proof composition lets you amortise verification of a batch into a single check, which is the only way the economics close for a mid-size operator.</p>
<p>But here is the caveat that the proof-of-solvency literature understates. <strong>A zero-knowledge proof over an incomplete set of liabilities is a mathematically valid proof of a false statement.</strong> The circuit guarantees soundness with respect to the committed inputs. It says nothing about the inputs the operator chose not to commit to. The cryptography is not the weak link. The scope of the commitment is the weak link, and scope is a legal and accounting question, not a cryptographic one.</p>
<h3>The Oracle Problem, Turkey Edition</h3>
<p>Now add the denominational complication, because this is where the Turkish case stops resembling the generic template.</p>
<p>A solvency circuit proves a comparison: liabilities against reserves. For that comparison to be meaningful, both sides must be denominated in the same unit. Turkish retail products are denominated in lira and their reserves are held in USDT, USDC, BTC, and gold. Somebody has to supply the exchange rate, and the exchange rate has to be trustworthy at the moment of proof.</p>
<p>Who supplies it? In current practice, the issuer. Or a third-party oracle the issuer pays.</p>
<p><strong>A Ponzi with a better oracle is still a Ponzi. It simply has a cleaner risk dashboard.</strong></p>
<p>The design fix is not to prove a ratio. It is to prove a floor. Do not attes the equality of liabilities and reserves at the spot rate. Attest that reserves in dollar terms exceed committed lira liabilities multiplied by a conservative floor rate — a lower bound supplied by a decentralised feed with a haircut applied, or by a regulator-set reference rate that the issuer cannot influence. That converts a manipulable equality into a conservative inequality, which is what a reserve attestation should have been from the beginning.</p>
<p>It also produces a property regulators should find attractive: it is falsifiable. A floor either holds at every block or it does not. There is no need to trust the issuer's risk model, because the attestation is binary.</p>
<h3>Risk Matrix</h3>
<table> <tr><th>Risk vector</th><th>Mechanism</th><th>Likelihood</th><th>Impact</th><th>On-chain verifiable?</th></tr> <tr><td>Custodial ledger fabrication (Type A)</td><td>Balances exist only in an operator-controlled database</td><td>High</td><td>Severe</td><td>No</td></tr> <tr><td>Owner exit via facade contract (Type B)</td><td>Single-transaction drain, no timelock or multisig</td><td>High</td><td>Severe</td><td>Partially</td></tr> <tr><td>Uncommitted liabilities (Type C)</td><td>Solvency proof scoped to a chosen subset of accounts</td><td>Very high</td><td>Severe</td><td>No, absent attestation</td></tr> <tr><td>FX oracle manipulation</td><td>Issuer-controlled reference rate inflates reserve ratio</td><td>Medium</td><td>Severe</td><td>No</td></tr> <tr><td>Label arbitrage</td><td>Operator denies being a crypto asset service provider to avoid the licensing regime</td><td>High</td><td>Moderate</td><td>No</td></tr> <tr><td>Enforcement lag</td><td>Detection-to-indictment gap exceeds exit-layer clearing time</td><td>High</td><td>Moderate</td><td>Yes</td></tr> <tr><td>Snapshot staleness</td><td>Point-in-time proof applied to a continuously accruing liability</td><td>Very high</td><td>Moderate</td><td>Yes</td></tr> </table>
<p>Two rows in that table deserve separate comment, because they are the ones that practitioners consistently misrank.</p>
<p>Snapshot staleness is rated very high not because operators are malicious, but because periodic attestation is the only cadence anyone has proposed. A quarterly reserve report on a product offering daily accrual is a report on a state that existed ninety days ago. The relevant metric is the accrual rate against the reserve trajectory, and that is a continuous function. Continuous attestation is technically feasible — recursive proofs make per-block or per-episode verification cheap enough to run without a dedicated hardware budget — but no regulator has yet written it into a rule, so no operator has an incentive to build it.</p>
<p>Enforcement lag is rated only moderate in impact, which understates it. The lag is not a delay in justice. It is a transfer of loss. By the time a file is opened, the exit layer has cleared: USDT sold peer-to-peer, converted to lira at an over-the-counter desk, moved into property, or flown. Tracing works on chain. It stops at the cash conversion. <strong>Cash out has no memo field.</strong></p>
<h2>Contrarian: What the Detentions Actually Signal</h2>
<p>The conventional reading of this week's dispatch is that Turkish enforcement is working. Executives are in custody. The apparatus responded. That is the reading you get from the headline, and it is the reading I think is wrong, or at least badly incomplete.</p>
<p>What the detention actually evidences is that the apparatus responds, on average, somewhere between eighteen months and three years after the first credible complaint, at a point when the on-chain trace is cold and the cash has dispersed. The rate-limiting step in this market is not prosecution. Prosecution is comparatively easy once you have a suspect, a bank record, and a chat log. The rate-limiting step is detection, and detection is underfunded because it produces no visible output. A case that never happens does not appear in any enforcement statistics. The incentive structure rewards the raid and not the radar.</p>
<p>The second blind spot is more consequential and it is a category error that the entire compliance conversation has made. Every regulatory obligation imposed on Turkish crypto intermediaries in the last three years concerns identity. Know your customer. Verify the source of funds. Screen against sanctions lists. Identity answers a real question: who is transacting, and are they permitted to.</p>
<p>It does not answer the question that every single depositor in a collapsing scheme actually has, which is: are the assets there.</p>
<p>Note what that means in practice. A Ponzi operator is not inconvenienced by KYC. The operator already knows exactly who its customers are, because it recruited every one of them through a referral tree. Identity verification imposes cost on honest intermediaries and near-zero cost on fraudulent ones. Meanwhile nobody is mandating a solvency attestation, and so the one regulatory instrument that would have made these schemes either honest or legible is simply absent from the rulebook.</p>
<p>There is an irony worth naming. Through 2025 I designed a privacy-preserving compliance layer for an institutional DeFi platform: a system that verifies solvency without exposing transaction histories, using zero-knowledge proofs to answer regulatory questions without revealing individual data. The primitive works. It is deployed. It is production-grade.</p>
<p>It is deployed for institutions. The retail depositor in a referral-tree scheme, the person whose entire problem is that they cannot verify reserves, is not the beneficiary of any of it. The technology arrived and then got pointed at the customers who needed it least. <strong>The primitive exists; the allocation is wrong.</strong></p>
<p>Third blind spot: the audit badge. In 2017 I submitted pull requests to two projects with reentrancy findings in their ICO contracts. One of them published an audit report and shipped the vulnerable bytecode anyway, where it stayed for months. I learned two things from that. The first is that an audit is a point-in-time opinion about a code artifact, not a continuous claim about a balance sheet. The second is that the badge is doing marketing work, not security work: it is purchased so the phrase “independently audited” can appear above the deposit button.</p>
<p><strong>Audits price the contract. Nobody prices the ledger behind it.</strong> A clean report on a Type C scheme is not misleading in itself. It is misleading in what it implies, which is a set of guarantees the report never made.</p>
<p>Fourth, and this is the part that makes all on-chain analysis systematically optimistic: the trust anchor in a broken-currency market is not a protocol. It is a person. The referral friend who got paid for three consecutive months is the risk model. That is the asset being pledged when a deposit is made, and it is not represented anywhere on a block explorer. It is why the on-chain footprint of these schemes is always an order of magnitude smaller than the victim count: most of the value moved as lira bank transfers and cash-in-hand, and only the sliver that touched USDT is legible. Chainalysis-grade tracing produces a number that underestimates the loss, and underestimates it for structural reasons rather than analytical ones.</p>
<h2>Takeaway: What I Expect in the Next Twenty-Four Months</h2>
<p>Three predictions, ordered by my confidence.</p>
<p>Within the next licensing cycle, the Turkish regime will move toward continuous reserve attestation for crypto asset service providers. The reason is not ideology. It is that the licensing regime has done the hard work for them: it has created an enumerated list of regulated entities that can be compelled. Attestation against a closed list is a tractable regulatory problem. Attestation against a general market is not, and for the unlicensed segment the enforcement path will remain criminal rather than preventive.</p>
<p>Second, expect the next generation of these schemes to migrate deliberately on-chain, into yield aggregator wrappers and vault structures that are designed to argue they are not crypto asset service providers at all. Nothing in the licensing regime defined an on-chain vault as a custodial service, and operators read rulebooks more carefully than anyone gives them credit for. The on-chain footprint will get larger and the legal surface will get smaller. That is not progress. It is relocation.</p>
<p>Third, the detentions will keep arriving eighteen months behind the wallets. The operational lesson is not that enforcement is failing; it is that enforcement was never the instrument that protects a depositor. Continuous, scoped, floor-based reserve attestation is. It costs a few hundred thousand gas per verification and a quarterly engineering budget.</p>
<p>The alternative costs the deposits of every participant in the next scheme, and the detention dispatch will still be eighty-four words long, and it will still contain no wallet address.</p>
<p>If the proof costs a few hundred thousand gas and the omission costs a few hundred thousand depositors, the question is not whether the primitive is affordable.</p>
<p>The question is who is currently incentivised to pay for it, and why the answer is nobody.</p>
<p><em>Code does not lie, but it often omits the context.</em></p>