On September 18, The Digital Chamber filed comments on NERC Project 2026-02, the first reliability standards written for computational loads: AI data centers, high-performance computing, and Bitcoin mining. The three standards cover interconnection, real-time operations, and disturbance monitoring. They apply to sites of 50 MW or more connected at 100 kV or above.
TDC supports the goal. Grid planners need to know how these loads behave, and developers need to know what the grid expects of them. But campuses with multiple connections, operating out of one site, need additional clarity to ensure that reporting obligations aren’t inappropriately levied on smaller partners at a site – a key point of our response. Additionally, TDC introduced the concept of decentralized distributed computational loads, and offered recommendations for new classifications in preparation for future mesh network buildouts.
Rules That Work for Every Operator
Compute is among the fastest-growing sources of demand on the grid, and projects need clear, workable rules. We see two areas where added clarity would help NERC reach its reliability goals:
Right-size costs across facility sizes. Modeling, monitoring, communications, and training cost about the same at a 50 MW site as at a 500 MW site, or roughly ten times more per megawatt. Costs that scale with system impact would keep small and mid-size facilities in the market.
Give distributed compute a clear home. Independently owned installations increasingly sell capacity into shared networks. Clarifying whether joining one makes a 2 MW owner a NERC-registered entity, and who is responsible when coordinated load moves across regions, would give owners and planners the same certainty.
NERC is finalizing Phase 1 while its roadmap sets Phase 2 priorities through 2027. TDC will stay engaged so NERC has the best information on current and future deployments.
TDC’s view
Reliability obligations should attach to the controller of electrical demand. Our comments ask NERC to:
Treat location as decisive. Common ownership, a shared scheduler, or a shared workload arrangement should not merge separate installations into one regulated site.
Define the aggregator by what it does. We proposed three new terms – Distributed Compute Resource, Dispatch Coordination, and DCR Aggregator – that place obligations on the entity coordinating load, modeled on FERC Order No. 2222 for distributed energy.
Separate control from commerce. Selling capacity a site can decline is not a change in grid behavior and shouldn’t trigger a restudy. Transfer of control, however, should.
Protect exit rights. Small operators must be able to leave an arrangement freely. Otherwise, the registered entity gains commercial control over its participants’ access to the grid.
Keep compliance proportionate. That means 18 to 24 months for first-time registrants, a materiality test for model re-verification, triggered data retention, and data limits tied to electrical behavior.
We also encouraged NERC to approach fast workload transfers between regions as a capability planners can see and coordinate, rather than only a risk to manage.
Getting these details right will help smaller operators, who carry the heaviest per-megawatt burden, build and compete alongside the largest campuses.
What’s next
NERC’s drafting team will review comments before revising the standards, and we look forward to working with the team and other stakeholders through that process. TDC has also recommended a dedicated Phase 2 workstream on coordinated distributed compute through the Large Loads Working Group. Our filing includes a supporting annex, “Distributed Compute Resources and the Aggregation Gap,” which details that framework.
TDC shares NERC’s objective: computational growth that proceeds alongside a reliable and resilient electric grid. Members running or planning computational load should contact the TDC policy team to share how these standards affect them.
As AI is increasingly integrated into our lives and national infrastructure, The Digital Chamber (TDC) has built policy principles to ensure that these vital systems preserves innovation, resiliency, safety, and a responsible federal-state regulatory harmonization that provides clear direction and protections for relevant stakeholders in the AI ecosystem. Specifically, the United States must refine regulations to leverage decentralized AI and AI development that supports open and democratic governance – technological remedies to many legacy AI roadblocks and concerns.
TDC supports the following principles that we intend to use to guide our AI policy engagement:
1. Mitigating Bias: Bias Audits Should Be Effective, Outcomes-Based, Transparent, and Public
AI systems should be tested for fair and non-discriminatory outcomes across their full lifecycle, not certified only once at launch.
TDC supports making bias-audit results available for regulator and public review, with the FTC and state attorneys general able to act where a consistent pattern of failed audits reveals discriminatory outputs. Bias audits should be tied to reasonable mitigation requirements, and at no point should mitigating bias be treated as the introduction thereof. Responsibility for biased outputs should generally rest with the deployer, the entity closest to the person affected, rather than falling equally on every upstream developer. The goal is a standard that measures results, rather than intent, as AI is definitionally incapable of producing ‘intent’ necessary for disparate-treatment claims.
2. Model Safety: Safety Disclosure Should Scale with Use Case, Not Model Size
Safety testing should be continuous and include:
pre-deployment evaluation
active monitoring,
an established process for addressing failing systems in real time
TDC supports disclosure requirements for safety testing results, calibrated to expected use case, user base, and associated risks, rather than model size alone. Systems deployed in healthcare, hiring, housing, or against a vulnerable population should meet a higher bar than a narrow tool with limited exposure, regardless of scale. Risk thresholds should reflect input from the people who bear the consequences of failure, and the workforce that identifies harm(s)deserves protections of its own.
Further, catastrophic risks have received outsized attention compared to more common violations of user rights and well-being. Both catastrophic and quotidian risks must be addressed.
3. Liability and Accountability: Accountability Should Follow Supply-Chain Role
Liability should track function: developers and deployers should each be accountable for harms tied to their specific role, and content-neutral infrastructure providers in a decentralized AI operating system should not be shoehorned into one of these existing categories.
Developers supply capability and are typically liable for defects in the underlying model (e.g., Meta is the developer of the Llama series). A party that modifies an existing model also takes on developer obligations where that modification expands the capability surface, alters the action space, or degrades safeguards;
Deployers refine capability and put it into use. This covers parties that fine-tune a model to narrow it within the intended purposes and documented limitations, and the entity that chooses to place a system into service. Deployers sit closest to the affected person and carry the greatest share of responsibility for outcomes in use. A deployer that narrows a model should publish its intended-use documentation and test for drift within that window;
End Users query or operate an AI system. Where the user and the affected person are the same, accuracy limits are disclosed, and a free and prompt remedy is available, liability should not run upstream for use outside the developer’s/deployer’s stated parameters. This limit does not apply where the affected person is not the operator, as in lending, hiring, housing, healthcare, and criminal justice.
These categories describe function, not identity, and are not mutually exclusive. A power user self-hosting a model may be developer, deployer, and end user at once. Contractual allocation should not displace the factual distribution of control.
Obligations also presuppose a party able to discharge them. Where a layer is permissionless and no entity controls access or output, assigning developer or deployer duties there accomplishes nothing or makes recentralization the only compliance path. Accountability should attach to parties exercising control, applied equally to concentrated and distributed infrastructure.
This chain should also make room for a distinct category of content-neutral infrastructure providers, including decentralized compute, storage, data-availability, and validation networks that do not select or control the models running on them, who should not inherit developer or deployer liability absent knowing participation in a specific harm (see Principle 9).
Each party should be able to explain the portion of the process it controls, and affected individuals should receive that explanation without requesting it or litigating for it.
4. Governance and Oversight: Human Oversight Is the Floor; Direct Governance Can Exceed It
Human oversight of consequential AI decisions – in lending, hiring, healthcare, housing, and criminal justice, among other high-risk domains – remains essential, as is government accountability.
Where a community (like a blockchain-based AI DAO) holds governance rights, that direct governance can fulfill accountability requirements.
Worker organizations and unions should be included as participants in setting oversight standards for AI directly impacting workers in a stakeholder model. Agentic AI should inherently carry identification metadata.
Further, that identification should extend to verifiable tamper-evident action logs, so an autonomous agent’s decisions can be attributed to a responsible party after the fact rather than reconstructed through litigation (see Principle 13). Mechanisms that build oversight directly into execution, such as network-level alignment nodes, illustrate how decentralized systems can make governance a property of the infrastructure rather than an afterthought.
5. Data Privacy and Sovereignty: Individuals Should Hold a Strong Claim to Their Own Data
Meaningful, rather than purely symbolic or perfunctory, control over personal and session data is essential.
Principled data sovereignty requires that people natively own their data. Privacy-preserving infrastructure, like decentralized identity and zero-knowledge methods, can help realize these protections.
Regulators should treat these privacy-enhancing technologies, including trusted execution environments and confidential computing, secure multi-party computation, and federated approaches, as affirmative compliance pathways deserving of safe-harbor treatment, rather than viewing their use with suspicion.
Reasonable limits on data brokers and concentrated data control can help enhance privacy where individual-level tools fall short. TDC also supports updated de-identification standards that account for AI-enabled re-identification risk.
6. Redefining “Democratic AI”: Legitimacy Comes from Governance, Not Governments
Democratic legitimacy is measured by how directly an AI stack’s power and governance is checked and how widely it is distributed, rather than by which government’s flag sits on a developer’s S1.
TDC believes AI development should build toward open, auditable, and decentralized AI, governed by meaningful direct input from the people it affects. Where that level of direct governance isn’t yet possible, legislative direction and generic guardrails can be a reasonable alternative.
Widespread use of a technology is not the same as widespread control over it. A system available to everyone and governed by one company is not democratic. Democratic AI should embody the following qualities:
Both control and usage are distributed. Many parties can run a system, but that is not the test. What matters is whether any single entity can unilaterally change the model, revoke access, or set the terms everyone else operates under.
The stack is open and forkable. Weights, training data, and code are published under terms that permit modification and redistribution. ‘Open source’ is a necessary but insufficient quality for Democratic AI.
Governance rights are enforceable. People affected by a system can change how it operates.
Decentralization also carries a resilience and security dividend that policymakers should weigh directly: infrastructure with no single point of control or failure reduces systemic risk and concentrated dependency. Advancing this standard should include interoperability, data and model portability, and open protocols, so that no single incumbent can capture the AI stack through lock-in.
7. Shared Societal Benefit: Democratizing AI Should Extend to Democratizing Its Gains
AI-driven labor disruption calls for near-term investment in reskilling and a modernized safety net, tracking impact as it happens rather than after the fact.
TDC believes that economic gains of AI should be widely distributed through consultation with civil society and affected populations. Workers and communities displaced by AI infrastructure should have a meaningful path to share the benefits of that infrastructure, rather than simply support for the disruption it causes.
Democratizing AI should extend beyond its oversight to who benefits from the tech, which should itself be decided democratically. Concretely, this can be delivered through verifiable on-chain attribution and micropayments to the people who contribute data, compute, and storage, and through participation in the networks those contributions help run. Such mechanisms distribute gains by design rather than only redistributing them after the fact (see Principle 12).
8. Verifiable AI:Cryptographic Proof Should Be a Recognized Path to Compliance
Compliance should be something a regulator can check, rather than something a developer asserts.
Audits, disclosures, and self-certification all ultimately ask the public to trust the party being regulated. TDC supports recognizing cryptographic verification, meaning proof of what model ran, on what data, and with what result, established through methods such as verifiable inference, provenance attestation, trusted execution environments, and zero-knowledge proofs, as a valid and, where available, preferred means of demonstrating compliance. A standard built on “verify, don’t just trust” lets oversight keep pace with systems too numerous and fast-moving to certify one at a time.
9. Neutral Infrastructure:Content-Neutral Providers Should Have a Clear Safe Harbor
Providing the pipes should not mean answering for the water.
The compute, storage, data-availability, and validation networks that AI runs on are typically content-neutral: they do not choose, train, or control the models they carry. TDC supports a clear safe harbor establishing that operating such infrastructure does not, by itself, make a party a developer or deployer, absent known participation in a specific harm. Without this, the decentralized and distributed infrastructure that makes open AI possible cannot operate at scale in the United States.
10. Digital Assets: Network-Incentive Tokens Deserve Regulatory Clarity
Decentralized AI cannot run on infrastructure that has no lawful way to reward its participants.
Decentralized networks coordinate and compensate their compute providers, storage providers, validators, and other contributors through functional tokens. TDC supports clear federal treatment confirming that tokens used to coordinate infrastructure and reward genuine network participation are not, by default, treated as securities, along with workable clarity for staking and other consensus mechanisms. Resolving this question, now under active debate in digital-asset market-structure legislation, is a precondition for a domestic decentralized-AI industry rather than a matter separate from AI policy.
11. Open Models:Releasing Open-Weight AI Should Be Presumptively Protected
Openness is both a safe and competitive strategy.
Open-weight and open-source models let independent researchers inspect, test, and improve systems that would otherwise be opaque. TDC supports treating the release of open-weight models as presumptively protected, so that a developer is not automatically liable for every downstream use of an openly released model and we are cautious about blanket reporting or restriction regimes aimed at open release. Where safety concerns arise, verifiability (Principle 8) is the better answer than closure: open and verifiable is more accountable than closed and unexamined.
12. Data Provenance:Contributors Should Be Traceable and Compensable
If data is the raw material of AI, its providers should be visible in the record and able to share in the value.
Verifiable data pipelines make it possible to record what data trained a model and to trace contributions back to their source. TDC supports on-chain, privacy-respecting data provenance together with mechanisms for attribution and compensation, including micropayments, to the creators and communities whose data trains AI systems. This advances content authenticity and consent while giving the shared-benefit commitment in Principle 7 a concrete mechanism.
13. Agentic AI:Autonomous Agents Need Identity, Accountability, and Payment Rails by Design
As agents begin to act and transact on their own, the accountability layer should be built in up front.
Autonomous agents increasingly initiate actions and transactions with limited real-time human involvement. TDC supports requiring that agents carry verifiable, portable identity, maintain tamper-evident logs of their actions, and remain attributable to a responsible human or entity, with any agent-to-agent transaction rails designed so that accountability is verifiable rather than reconstructed after harm. Building these guarantees into the infrastructure is the most reliable way to keep an emerging agentic economy answerable to the people it affects.
First,existing law already covers most of what worries people about AI in finance. The Equal Credit Opportunity Act, the Fair Housing Act, the Fair Credit Reporting Act, and Dodd-Frank’s UDAAP provisions don’t carve out an exception for a decision a model made instead of a person. Congress’s first job is reviving and enforcing the rules already on the books, rather than building a parallel AI-specific regime.
Second, compliance claims should be provable, rather than asserted by private companies. Tamper-evident action logs, cryptographic attestations, and verifiable model and data provenance records let a regulator or a court confirm which system acted, on what data, and whether the record was altered afterward. None of that replaces governance, testing, or supervision, but it strengthens self-certification with an authoritative audit trail.
Third, liability should follow function and control, rather than a party’s position in the supply chain. A developer that sets a model’s behavior, and that a deployer can neither inspect nor alter, should answer to the consumer. We also asked Congress for the reverse protection: a safe harbor for content-neutral infrastructure. Compute, storage, and validation networks that carry AI without selecting or training the models running on them shouldn’t be treated as developers or deployers simply for existing, and that protection should apply whether the infrastructure is centralized or distributed.
Data Centers, Front and Center
We also weighed in on AI data centers. We asked the Federal Energy Regulatory Commission to assign the transmission and generation costs a large load causes to that load, instead of spreading them across every customer in the region. We asked Congress to give the Energy Information Administration authority to collect mandatory facility-level reporting on power and water use, because fragmentary data reporting obligations leave communities without the information they need to make informed decisions. And we pointed the Committee to decentralized AI architectures, workloads distributed across many smaller machines instead of concentrated in one location, as a way to ease grid pressure and democratize the AI stack.
Committee Democrats will fold this response into future hearings and legislation on AI in financial services and housing. TDC’s position gives them a path that doesn’t force a choice between protecting consumers and letting the industry keep building: rules that already exist, evidence a regulator can check, and liability that lands on whoever actually controls the outcome.
Bitcoin’s security rests on a simple promise: only the owner of a private key can spend the coins tied to it. A cryptographically relevant quantum computer, or CRQC, could break that promise by working backward from an exposed public key to the private key behind it. New research from Google Quantum AI cut the estimated hardware needed to pull this off by roughly 20x, down to fewer than 10,000 physical qubits.1 The same research puts nearly 7 million BTC, close to a third of the supply, in addresses where the public key is already out in the open and ready to attack.2 Two Bitcoin Improvement Proposals, BIP-360 and BIP-361, lay out how the network closes that gap.
Why This Matters Now More Than Ever
Bitcoin has no CEO who can push a patch. Every rule change needs miners, node operators, and users to separately choose to adopt it – a process that took years even for widely-supported upgrades like SegWit and Taproot. That slow clock is exactly why the runway needs to open now: the hardware estimates keep shrinking, but the migration path doesn’t get any shorter. A quantum attacker also doesn’t need to hit every wallet at once. One exposed key is enough, and nothing stops the attacker from sitting on stolen funds for months before moving them, timing the theft to avoid drawing notice from chain watchers.3
BIP-360 introduces a new output type, Pay-to-Merkle-Root (P2MR), so newly minted coins never expose a raw public key in the first place.
BIP-361 sets a public deadline for moving already-exposed coins to quantum-resistant addresses, after which the network stops honoring spends from the old, vulnerable signature types.
Together, they cover both the coins Bitcoin hasn’t minted yet and the coins already sitting in the open.
TDC’s View
We recommend implementing both BIP-360 and BIP-361. Bitcoin’s coordination problem is also its risk-distribution problem: no central authority can force anyone to upgrade, so the burden of acting falls unevenly. Well-capitalized exchanges and miners can migrate on their own timeline. Retail holders and dormant accounts, including an estimated 1.7 million BTC in wallets whose owners are lost, dead, or simply gone, cannot act at all, no matter how much warning they get. Waiting for a crisis to force the industry’s hand doesn’t spread that exposure more fairly; instead, it leaves ordinary and absent holders exposed while everyone with the resources to move fast does exactly that. A public timeline is what makes the migration workable instead of a scramble, and it’s the best option the network has to protect the self-custody promise that makes Bitcoin worth defending.
What Happens Next
BIP-360 and BIP-361 are proposals, not settled code. They still need the community to build consensus, wallets and exchanges to support the new address types, and node operators to adopt the rules that enforce them. We will continue to track the process and keep members briefed as it moves through review, pressing the industry to treat this as a planning problem to solve now, rather than an emergency to manage later.
