Neutrality is critical. It determines who controls the system. Who controls the system decides how the system is regulated. Remember that for later.

The Credible Layer is a decentralized, neutral network extension. As middleware, the Credible Layer extends network capabilities without introducing new trust assumptions: protocols define security rules through existing governance channels, and networks enforce binary rules through existing mechanisms.

It is an open protocol that does not put users at risk of vendor lock-in. Networks can remove the Credible Layer anytime without disrupting their core functionality. dApps can remove or add assertions anytime. The system also passes the off-switch test.

When a network removes the Credible Layer, it simply stops enforcing each protocol's assertions; the protocols retain all functionality, and their assertions remain defined. Anything resembling lock-in comes from the dApps applying social pressure on the network because they want to continue to use the tech, rather than forced dependence on a vendor.

By avoiding centralized control points, this architecture preserves decentralization for both dApps and networks. This could become more important in the near future. New regulations, like the CLARITY Act and MiCA, that seek to clearly define and carve out truly decentralized projects while capturing decentralized-in-name-only projects are coming. Every new trust assumption and centralized control point puts a network at greater risk of falling on the wrong side of that line.

How This Works

Protocol Layer (definition): A DeFi protocol's DAO votes to add an assertion: "No ownership changes for the contract." This becomes executable code stored on-chain. It can be removed anytime.

Network Layer (enforcement): The block builder validates transactions against this assertion before including them in blocks. If a transaction would cause an ownership change, it's dropped by the network.

Neutrality Across Governance Models

The Credible Layer maintains neutrality regardless of how protocols make decisions.

In highly decentralized protocols with thousands of token holders, assertions are added through standard governance proposals that require community consensus.

For moderately decentralized protocols using a multi-sig with a timelock, the multi-sig proposes assertions while the timelock provides a delay for community feedback, then the network enforces the assertions once they have been enabled.

Centralized protocols with single admins can use assertions, where the admin defines assertions directly and unilaterally. Assertions can be deleted, archived, or edited through all the same processes.

In each case, the Credible Layer conforms to the existing governance structure, adding no trust assumptions or centralization points.

Neutrality Across Network Architectures

The Credible Layer also maintains neutrality across different network structures.

On a single sequencer L2 like Base, the existing sequencer becomes the Assertion Enforcer using the same infrastructure. It can be removed anytime, which would disable that network from enforcing assertions written by dApps on that network.

On multi-builder networks like Ethereum, we're exploring mechanisms where protocols can restrict which blocks can include transactions that interact with their contracts. Rather than protocols directly routing transactions to specific builders, the system would likely involve protocols defining which builders are authorized to include their transactions in blocks. This could work through allowlists of credible builders or transaction validation requirements that only participating builders can satisfy. The exact implementation remains under development, but the core principle is ensuring that transactions interacting with assertion-protected protocols can only be included by builders who enforce those assertions, preventing circumvention through non-participating builders.

Again, in each case, the Credible Layer fits into the existing architecture, adding no trust assumptions or centralization points.

Regulatory Ramifications

Remember, at the beginning of this, you read “Who controls the system determines how the system is regulated.”

Well, that’s what this next part is about.

The Clarity Act is a piece of legislation that is currently moving quickly through Congress. Among other things, it would define what it means to be a decentralized system and, importantly, exclude from regulatory obligations systems that qualify. The act requires "mature blockchain systems" not to be "controlled by any person or group under common control."

As mentioned above, the Credible Layer adds no new control points—if a network and its protocols qualify as mature systems today, they remain qualified with Credible Layer.

Other approaches to security create explicit what the bill defines as "unilateral authority to control or materially alter functionality." An AI security provider can unilaterally change their algorithms. SaaS companies can modify security policies and manage enforcement. These capabilities seem to match what disqualifies “mature system” status.

Similarly, the EU's Markets in Crypto-Assets (MiCA) regulation emphasizes operational resilience and governance transparency, favoring systems where control mechanisms are clearly defined and auditable rather than opaque or externally managed.

Traditional finance has faced similar control questions for decades. Here are a few examples:

SEC Regulation S-P requires firms to maintain "written policies and procedures that address administrative, technical, and physical safeguards for the protection of customer records and information."

FINRA Rule 3110 requires firms to establish written supervisory procedures to supervise activities and achieve compliance. Both regulations assume the firm controls its procedures and can document them transparently.

When traditional financial firms outsource security decisions to AI providers or external monitors, they face regulatory scrutiny about who controls their supervisory procedures. The question becomes: if an external system makes security decisions without the firm's written procedures covering those decisions, who is supervising?

Consider a lending protocol using an AI security system that flags all transactions from certain addresses as "suspicious." The AI provider made this decision without protocol governance approval, creating "unilateral authority" that violates mature system requirements.

Or the alternative: the same protocol defines an assertion, "Loans cannot exceed 80% LTV." This rule is set by protocol governance, enforced by the network, and cannot be changed without repeating the governance process.

No unilateral authority exists. Additionally, every rule is visible to the world.

The following is just how we think a regulator would view it from a plain reading of the language:

Scenario 1: Credible Layer

  • Protocol governance: Published assertion: "No ownership changes."
  • Enforcement: Transactions violating this rule are rejected by the network.
  • Regulatory view: The protocol sets its assertion through governance, which is enforced by the network and is easily auditable.

Scenario 2: AI System Hack Prevention

  • AI system: "This transaction is suspicious, blocking it."
  • Enforcement: The AI provider made a unilateral decision.
  • Regulatory view: AI provider has "unilateral authority to control.” Neither the dApp, the user, the network, nor the regulator knows exactly why the enforcement took place.

Scenario 3: SaaS Security Rules

  • SaaS provider: "Blocking transaction - violates part of the ruleset"
  • Enforcement: External service checking rules and making enforcement decisions
  • Regulatory view: SaaS provider has "unilateral authority to control" - can change security policies that affect protocol operations

Where Non-Neutral Solutions Fail

AI Security Systems: Create new centralized decision-makers who can change behavior without governance approval. Impossible to audit due to opaqueness. The chain and the network have to trust this 3rd party.

SaaS Security Solutions: Require protocols to trust external entities for critical security decisions. Additionally, users suffer from lock-in and failure to pass the off-switch test.

If you remember anything from this blog in a week, let it be this:

Non-neutral alternatives force protocols to choose between security and decentralization. The Credible Layer proves this is a false choice. By remaining neutral across governance models, network architectures, and regulatory frameworks, it offers a path forward that strengthens both security and decentralization simultaneously.