Frequently Asked Questions & Answers
SECTION 8: Security & Technology
This section addresses the practical, technical questions people naturally have about a blockchain-based monetary system — including the honest limits of what the technology can and can't guarantee.
Blockchain is used because every previous attempt to anchor money to something real — gold, commodities, physical reserves — depended on a single central authority to verify that anchor, and every one of those central authorities eventually broke its commitment under political pressure; blockchain is the first technology that makes a verification system possible with no central point that can be captured at all.
For roughly three thousand years, anchoring money to physical reality has faced the same unavoidable trade-off: you need someone to verify that the underlying reality is genuine, and that verifier has always been a central institution — a royal mint certifying coinage, a treasury certifying gold reserves. Every one of these arrangements has eventually failed, not because the underlying physical reality disappeared, but because the institution responsible for verifying it was captured, corrupted, or simply abandoned its commitment when honoring it became politically inconvenient. The gold standard wasn't abandoned because gold ran out — it was abandoned because governments found that nothing but their own institutional integrity prevented them from breaking their word, and that integrity didn't survive the pressures of war and economic crisis (see Question 6, Section 1).
Blockchain technology changes this equation for the first time in monetary history. By combining a distributed public ledger, decentralized "oracle" systems that bring verified real-world data onto the chain, and self-executing smart contracts, it becomes possible to build a verification system with no single point of control — one enforced by mathematical consensus across many independent participants rather than by the goodwill of one institution. A financial power that wanted to corrupt the system would need to simultaneously compromise a majority of independent, randomly assigned validators, rather than simply capturing one central authority.
Related: Question 33 (Section 3) for how this builds specifically on what Bitcoin proved was possible; Question 65 for whether this makes the system unhackable.
Learn more: Chapter 4.4, "Why Blockchain Makes This Possible Now" (p. 205–211)
63. Why blockchain?
In a narrow technical sense, you could build the SVP's bookkeeping with a conventional database — but doing so would simply recreate the exact vulnerability that has undone every previous attempt at production-anchored money throughout history: a central authority capable of being captured, corrupted, or politically pressured into abandoning its commitments.
This question is worth taking seriously rather than treating blockchain as a fashionable default. A centralized database, administered by some trusted institution, could technically record production events, mint tokens, and distribute dividends using rules similar to the SVP's. But that database would depend entirely on the honesty of whoever controls it — and the book's entire historical argument, running from the debasement of ancient coinage through the abandonment of the gold standard to the ending of Bretton Woods in 1971 (see Question 6, Section 1), is that centralized verification authorities reliably fail exactly when they're under the most pressure to fail, because there's nothing structurally preventing that failure beyond institutional goodwill.
Blockchain's distributed architecture is what allows the SVP to make a genuinely different and stronger claim than any previous production-anchored monetary system: that no single institution — including the SVP's own founders or Genesis Validator Council — can unilaterally alter the money-creation rules or the record of what's happened. That specific property, structural resistance to capture, is what blockchain provides that a conventional database administered by a trusted authority cannot. Whether that property is "necessary" depends on what you're trying to build: a bookkeeping system, no; a monetary system designed to remain honest even when it becomes valuable enough to be worth corrupting, yes.
Related: Question 35 (Section 3) covers this same question from the perspective of what problem blockchain specifically solves; Question 9 (Section 1) for why the current system's design choices weren't inevitable either.
Learn more: Chapter 4.4, "Why Blockchain Makes This Possible Now" (p. 205–208)
64. Is blockchain necessary?
65. Can the system be hacked?
No monetary system can honestly claim to be completely unhackable, and the SVP's designers explicitly don't make that claim — instead, the protocol is built so that the realistic cost of a successful attack (in staked capital lost, coordination required, and detection risk) consistently outweighs any plausible gain, and several categories of residual risk are openly acknowledged rather than hidden.
The book presents its security model as a structured threat analysis rather than a marketing claim, naming specific categories of attacker and the corresponding defense: a lone producer trying to fake evidence faces a four-layer verification system requiring multiple independent physical evidence sources (see Question 46, Section 5); a producer colluding with a buyer faces the reality that the buyer must either pay real money for a nonexistent commodity or submit a payment record that doesn't match — both of which are detectable; a group of validators trying to approve a fraudulent claim together needs to corrupt at least three randomly assigned people simultaneously, each risking their entire staked deposit; and an attacker trying to compromise the oracle data sources faces a system that deliberately spreads data collection across multiple independent providers so no single one can be relied on alone.
The book is also candid about what remains genuinely difficult to fully solve: small-scale, long-term collusion between trusted parties that stays under detection thresholds is acknowledged as a real residual risk, as is the theoretical possibility of a major oracle data provider being compromised. None of the protocol's designers claim these risks are eliminated — only that they're managed down to the point where, for any rational actor, attempting fraud is a losing financial bet.
Related: Question 47–49 (Section 5) for the full detail on how fraud specifically is deterred and detected; Question 86 (Section 10) for the broader honest risk assessment the book offers.
Learn more: Chapter 5.7, "Security Model: Defending Against Monetary Counterfeiting" (p. 285–293)
66. Is everyone's financial information public?
Transaction activity itself — every minting event, every dividend payment, every governance vote — is fully and permanently public on the blockchain by design, but this is closer to how Bitcoin works than how a bank statement works: wallet addresses aren't automatically tied to a visible real name, even though the registration process itself does require identity verification to prevent fraud.
Transparency is a deliberate, foundational design choice in the SVP, not an accidental side effect — the book repeatedly emphasizes that every minting event, dividend distribution, and governance decision is recorded on a public blockchain that any community member can inspect at any time, specifically so the system's honesty can be independently verified rather than trusted on faith (see Question 51, Section 6). This means the flow of tokens — how much a given wallet received, when, and from what kind of transaction — is genuinely public information, visible to anyone with an internet connection.
What's different from a fully public bank statement is that a wallet address, on its own, doesn't display a person's name — it's a cryptographic identifier, similar to how Bitcoin addresses work. That said, becoming eligible for the Universal Dividend does require completing the protocol's identity verification process to confirm you're a genuine, unique community member (this is what prevents someone from registering many fake wallets to collect multiple dividends — see Question 48, Section 5). That verification link between a real person and their wallet is held through the registration process, not broadcast as part of every public transaction record. In short: the community's collective financial activity is radically transparent by design; a given individual's real-world identity isn't automatically attached to that public record the way it would be on, say, a public social media post.
Related: Question 51 (Section 6) for why this transparency is treated as foundational to the protocol's legitimacy; Question 50 (Section 5) for the identity requirements around becoming a validator.
Learn more: Chapter 6.2, "Who Controls the Money Supply" (p. 318), and Chapter 5.3, "The Universal Dividend: UBI Without Taxation or Borrowing" (p. 241)
67. What happens if computers fail?
Because the Resource Credit Chain is validated by a distributed network of many independent nodes rather than any single server, the failure of any individual computer — or even several — doesn't take the system down; the protocol specifically requires validators to be spread across multiple geographic regions precisely so that a localized outage can't disable the network.
A blockchain's core resilience property is that it doesn't depend on any one machine staying online. The Resource Credit Chain's consensus process draws on a distributed pool of validator nodes, with only a randomly selected subset needed to confirm any given block or production event (a 3-of-5 quorum for standard confirmations — see Question 49, Section 5). As the network grows, the protocol's own deployment requirements call for validators to be spread across at least three distinct geographic regions, with no single entity controlling more than 15% of the network's total staked capacity — a diversity requirement explicitly designed, in the book's own words, "to prevent coordinated regional outages" from disabling the network.
An individual validator going offline is an expected, unremarkable event handled by the protocol's ordinary design — extended, unexplained downtime beyond 48 hours triggers a partial slashing of that validator's stake, which is both a consequence for unreliability and an incentive for validators to maintain resilient infrastructure. What the design protects against is any single point of failure disabling the whole system; it doesn't promise that any individual participant's own hardware or internet connection is immune to problems.
Related: Question 50 (Section 5) for the requirements around becoming a validator in the first place; Question 68 for the related question of internet connectivity specifically.
Learn more: Chapter 5.8, "The Four Phases of Network Deployment" (p. 302)
68. What if the internet goes down?
This is a genuine, honestly acknowledged dependency rather than something the protocol claims to solve — participating in the SVP requires internet connectivity adequate to run a wallet application and transmit oracle data, and the book relies on the ongoing global spread of mobile and smartphone access to make this practical rather than presenting a technical workaround for full offline operation.
Unlike some of the SVP's other design choices, this isn't a problem the protocol has engineered its way around — it's a genuine, acknowledged requirement. The book's own onboarding criteria for new communities explicitly list "digital connectivity adequate for wallet applications and oracle data transmission" as a prerequisite for joining the network, alongside things like demonstrated production activity and existing community governance institutions. If a community — or an individual within one — has no internet access at all, they genuinely cannot interact with the blockchain during that outage: no minting confirmations, no dividend distribution checks, no governance voting.
What does work in the protocol's favor here is the same trend that has made mobile banking viable across regions that never had access to conventional banking infrastructure: rapidly expanding smartphone and mobile data penetration across the developing world, which is precisely why agricultural cooperatives, indigenous communities, and fishing cooperatives in regions with historically limited banking access are identified as natural early adopters (see Question 31, Section 3). The distributed validator architecture also means that a localized outage in one region doesn't take down the network for everyone else — but for the specific individuals or communities experiencing that outage, connectivity is a real, practical requirement, not an optional convenience.
Related: Question 69–75 (Section 9) for more on how communities with varying levels of existing infrastructure actually adopt the protocol; Question 67 for how the network handles hardware and node failures more broadly.
Learn more: Chapter 5.8, "The Four Phases of Network Deployment" (p. 302)