ZK Nation

DAWO26 · The Future of the Firm

Software as a substrate of control

Follow along
npc.here.now/dawo2026workshop2control

Overview

Executive summary

  • Software increasingly mirrors our physical built environment.
  • Control continuously migrates into software, and is then inherited by future organizations.
  • Control can be hard, making certain actions unreachable, or soft, requiring compliance.
  • DAOs can be unbundled into their software primitives, some hard, some soft.
  • Software control primitives predate blockchain and AI agents, so only the principal is new.
  • Recent case studies of software controls include multisigs, ZKsync capped minters, version control, and runtime guardrails.
  • Hardness is just a matter of the energy (or innovation) needed to break it.

Get in touch at rafael.fyi, download the slides at npc.here.now/dawo2026workshop2control. Learn more about ZKsync at docs.zknation.io, and the Protocol Institute at protocol-institute.org.

About

Rafael Fernández

  • Group Research Lead at the Protocol Institute (Protocols for Business) and Director of the ZKsync Association.
  • Architect of ZKsync’s three-body governance — Token Assembly, Security Council, Guardians — live on mainnet since 2024.
ZK Nation logomarkZKsync Association

A non-profit association under Austrian law and the issuer of the ZK token. It is home to the ZKsync Governance Team and ensures that all activity involving the token complies with the EU Markets in Crypto-Assets Regulation (MiCA).

Protocol Institute logomarkProtocol Institute

A research, education, media, and scene-making organization dedicated to advancing protocols and protocolization worldwide. Its work runs under the tagline “Accelerating Order,” across institutional research and a literary magazine.

rafael.fyi  ·  rafa@zknation.io  ·  Telegram @rafathebuilder0x  ·  Berlin

Definition

It’s a matter of “control”

  • Control is “purposive influence toward a predetermined goal” (Beniger, The Control Revolution, 1986, 7–8). It spans a gradient from influence to determination.
  • Substrate is our water: the sediment of “decisions, documented conventions, test suites, and exception history that loops read from and write to” (Kyle Matthews, bricolage).
  • Hard (structural) control: rules enforced by the substrate itself; non-compliant actions are unreachable.
    • Akin to Lessig’s architecture, which “sets the terms on which life in cyberspace is experienced” (Lessig, “Code Is Law,” 2000); Reidenberg’s Lex Informatica, “the set of rules for information flows imposed by technology and communication networks” (Reidenberg, Tex. L. Rev. 76, 1998, 554–55); and Josh Stark’s “hardness,” engineered through blockchains after atoms and institutions (Stark, “Atoms, Institutions, Blockchains,” 2024): ex ante, self-executing, no enforcement agent required.
  • Soft (advisory) control: law, norms, markets, and policy that operate ex post on the actor’s decision; compliance remains a choice (Lessig, “The New Chicago School,” J. Legal Stud. 27, 1998).

Physics test

Control is hard if and only if violating the rule is physically or computationally impossible within the access boundary.

Framing

Control is migrating into software

Drivers differ by case; some examples

  • Remove single points of failure.
  • Distribute authority among parties who need not trust each other.
  • Bound delegated authority and reduce custodial risk.
  • Coordinate contributors with no central gatekeeper.
  • Constrain autonomous agents whose actions outpace per-action human review.
  • Rules encoded in software are applied uniformly, in advance, and are auditable.

Result

Software control reshapes the locus of human discretion, often acting as guardrails before discretion can be applied.

Case study 01

Multisigs

DriverBlockchain asset risks.

  • A transaction is valid only if m-of-n predefined signatures are present.
  • A single key authorizes nothing. Below the threshold, validating nodes reject the transaction.
  • Enforcement is performed by protocol validation, not by participant conduct.
  • Implementations include Safe (Ethereum), Bitcoin P2SH/P2WSH, and threshold-signature (MPC) schemes.

AsideMultisig applies a centuries-old security principle known in banking as “dual control”: just as a safe-deposit box opens only when the renter’s key and the bank’s guard key are turned together, and a multi-lock strongbox required each of its custodians to bring a separate key, funds move only when several independent keyholders sign.

Case study 01 · Participants

Software participants: humans, agents (AI), sub-organizations

  • The scheme does not depend on the type of signer.
  • An autonomous agent can hold one of the n keys: it can propose and co-sign, but it cannot move funds alone.
  • A sub-organization, such as a team or a downstream DAO, can hold a key on the same terms.
  • The maximum effect of a single compromised signer is bounded by the m-of-n threshold.

Case study 02

ZK token capped minters

DriverBlockchain custody risk; refocus token governance on mechanics rather than asset-investment strategy.

  • The ZK token supply cap is 21,000,000,000.
  • A capped minter delegates minting authority under fixed limits, instead of pre-minting the supply to a single treasury.

Parameters — set at deployment, immutable

  • cap: the maximum number of tokens the contract may mint.
  • startTime / expirationTime: the window in which minting is permitted.
  • Rate limit (optional): for example, up to 1,000,000 ZK per month.
  • A mint that exceeds the cap, falls outside the window, or exceeds the rate reverts.

Roles

  • The admin assigns and revokes the minter role, and can pause or cancel minting.
  • The minter chooses the amount, timing, and destination within the fixed limits.
  • Governance cannot raise a deployed minter’s cap. It can authorize new minters or raise the token supply cap through a protocol upgrade.

Framing

  • Constitutional versus post-constitutional choice (Buchanan & Tullock, 1962): the rules are set once, at deployment, and actions occur within the rules, at minting.
  • Immutable rules may fix what is allowed, but not necessarily who decides which allowed actions get executed, or in what order.

Case study 03

Version control (non-blockchain controls)

DriverCoordinate contributors with no central gatekeeper.

  • Access defaults — who can merge, approve, or push a tag — determine who can change a shared repository.
  • Git distributes the ability to contribute to a repository, so control shifts from access permission to acceptance of proposed changes.
  • Maintainer authority is constrained by the option to fork.

Case study 04

Runtime guardrails (non-blockchain controls)

DriverActions outpace human temporality.

Examples

  • Execution sandbox (Firecracker / gVisor): isolates the agent from the host.
  • Egress allowlist proxy: default-deny on outbound network traffic.
  • Scoped ephemeral credentials: per-task tokens with short expiry.
  • Cost and rate circuit breaker: a spending ceiling checked before execution.
  • Deny-by-default capability gate: tool access mediated by an external policy engine.

Analysis

Some controls are hard, others are less so

Soft · advisory

  • Requests compliance; the actor is asked to behave.
  • Examples: system prompts, policies, alignment.
  • Can be bypassed under prompt injection, model drift, or incentive.

Hard · structural

  • Makes the constrained action unreachable; holds regardless of the actor’s decision.
  • Examples: multisig, capped minters.
  • A fully adversarial actor cannot reach the action; a prompt instruction (“do not mint more than X”) can be ignored.

Physics test: could a fully adversarial actor still reach the action? If yes, the control is advisory; if no, it is structural.

Discussion

Prompt questions

  1. Where does software already say “no” in the systems you study, or institutions you participate in? How were these controls set?
  2. How do hard guardrails differ, if at all, from centralization?
  3. What are the second-order costs of encoding control — maintenance, entrenchment, reduced adaptability — and how should we theorize that trade-off?
  4. The DAO evidence says central control lowers collective innovation. Do hard guardrails lead to the same result?
  5. Which established constructs — authority, hierarchy, organizational boundaries, incentives — need revision once control migrates into software?
  6. What are examples of new and emerging hard code controls?
  7. Where is the “software as a substrate of control” framing wrong or incomplete?

Contact and further reading

Thank you

rafael.fyi  ·  rafa@zknation.io  ·  Telegram @rafathebuilder0x  ·  Berlin

Further reading

Software as a substrate of control
01 / 13