Nocturn Foundation [prepublish].md

01_NF-alpha.md

The Nocturn Foundation - Section 0x

Ethereum has builders.
Ethereum has searchers.
Ethereum has validators.
But Ethereum has no dedicated protectors.

The Nocturn Foundation proposes a new actor class: the Nocturn.

A Nocturn is an Ethereum validator that relays normally - but proposes blocks only when required for chain-saving interventions: rescues, frozen assets, exploit mitigations. It is not a searcher, nor a MEV actor. It is a defender.

Nocturns form a decentralized alliance of validators committed to intervening only when no one else will, and never for profit unless value is returned, burned, or transparently allocated.

There was a time when Ethereum couldn’t act.
Today, it can.

If Vitalik once said "If I knew 15 years ago what I know now...",
then this is our answer to that hindsight:

A chain that doesn’t wait for tragedy to justify coordination.
A validator role that does not ask for permission - only for intent.

Nocturns mark Ethereum's transition from reactive to prepared.

---

When Correction ≠ Rollback

Nocturns do not rewrite history. They write what history forgot to protect.

In the rare cases where a Nocturn proposes a block that appears to "undo" something, it is not a rollback. It is:

• A validator assigned by protocol chance
• Acting with public rationale and intent
• On a slot they did not choose, but were granted

This is not a fork. This is not a reversion. This is coordinated forward motion under ethical constraints.

Only the protocol can assign the right to act.
Only intent can justify using it.

A rollback requires collusion.
A Nocturn requires coincidence - and courage.

You can’t trigger a Nocturn. Only the protocol can.

---

Protocol Alignment and the Role of Intent

The greatest threat to whitehat interventions isn’t technical. It’s ethical ambiguity.

Victims often know they’ve been scammed.
Whitehats can trace the funds.
Even protocols may recognize the incident.

Yet action stalls - not because of doubt, but because of lack of permission.

The Answer: Protocols That Align to Intent

Nocturns don’t ask for special rules.
They ask for a moment of clarity: when intent meets capability.

Imagine a protocol that says:

require(
  NocturnRegistry.isNocturnBlock(block.number) &&
  block.timestamp > user.unstakingTime,
  "Wait for integrity checkpoint"
);

Then suddenly:

• Protocols don't blindly unlock - they unlock on purpose
• Rescues align to the protocol, not the other way around
• A Nocturn block becomes an integrity checkpoint

---

Pig Butchering: Billions Lost to Silence

Pig butchering scams have cost victims billions.
Not from technical hacks - but from emotional targeting.

"I thought I was staking on Ethereum.
I believed in the protocol.
I just didn't know the app wasn't real."

These victims weren’t naive. They were betrayed by interface and silence.

And today, the rise of generative AI blurs that line even further - between interface and intent, between sincere invitation and scripted deception. What looks like a dApp may be a deepfake. What feels like trust may be synthetic persuasion.

The credibility gap is closing - not because truth has improved, but because lies have scaled and scammers have become more bold than ever.

The burden often falls on non-technical users - retail stakers, DAO voters, everyday holders - to interpret, decide, and act across interfaces they do not control. They are on the front line, facing increasingly human-like deception with no assurance of alignment.

The risk isn't just code. It's cognitive overload, social manipulation, and timing pressure - all amplified by automation.

Nocturns offer Ethereum a way to reply:

"If this really was positive staking -
we'll meet you at a Nocturn block, and bring you back."

Whitehats shouldn’t beg for slots.
The chain should give them.

When protocols anchor their timing logic to Nocturn blocks,
rescues stop being exceptional - they become intentional.

Ethereum gains a scheduled defense layer,
not as a fork, not as an L2,
but as part of its heartbeat.

---

The Ethical Heartbeat of Ethereum

Nocturns don’t override consensus. They honor it.
They operate on the very slots the protocol chooses.
Their power is not derived from a backdoor, but from alignment:

• With victims
• With protocols
• With public rationale

A Nocturn doesn’t compete - it completes.
What was missing from the ledger is reintroduced not by force, but by opportunity.

Every protocol can choose to support Nocturn blocks as checkpoints.
Every validator can choose to become a Nocturn.

We do not need everyone.
We only need a few - aligned, courageous, prepared.

---

From Passive Observation to Intentful Defense

Ethereum has spent much of its life building walls:
immutability, censorship resistance, neutrality.

Now it must learn to build doors -
ethical pathways to bring people back in when fraud has pushed them out.

Nocturns are not about rewriting.
They are about resynchronizing with what Ethereum wants to be:

• A place where belief in the protocol is rewarded
• A network that acts when intent is clear
• A validator class that defends - even in silence

This is not exceptionalism. It’s preparedness.

---

A Place to Call Home Again - Without Shame

To the victims:
You are not forgotten.

To the protocols:
You can choose to unlock - with integrity.

To the whitehats:
Your courage deserves coordination.

To Ethereum:
The next layer of defense is not a smart contract.
It’s a validator.

It’s a Nocturn.

02_nocturn_clarifications_addendum.md

Addendum 1: Clarifications and Projections

Clarifications

Proposer Lookahead

In Ethereum's Proof-of-Stake mechanism, each validator knows in advance when they will be selected to propose a block - typically one epoch ahead (about 6.4 minutes).

This lookahead window allows Nocturns to:

• Prepare rescue payloads if needed
• Coordinate with other Nocturns for multi-slot execution
• Verify bundle validity ahead of time

The key distinction is this:

Nocturns don’t just get lucky. They get ready.

Ethereum’s architecture provides the window. Nocturns provide the intent.

Nocturn Blocks Frequency

• A Nocturn block is not manually chosen; it is assigned by the validator lottery.
• However, protocols can choose to recognize and react to them.
• Target cadence for usable Nocturn blocks: every 3–5 minutes, assuming sufficient validator adoption.

Triggering Conditions

• A Nocturn block does not override protocol logic.
• Instead, protocols can opt-in to include checks such as:

require(
  NocturnRegistry.isNocturnBlock(block.number),
  "Wait for Nocturn checkpoint"
);

This turns a regular slot into a moment of opportunity.

RaptorCast Coordination and Eclipse Resistance

Nocturn validators use RaptorCast - a lightweight, high-speed gossip mechanism - to communicate across their lookahead windows.

This enables:

• Pre-slot coordination of rescue bundles
• Peer-to-peer confirmation of validator intent
• Secure relay of payloads even under eclipse or network manipulation

Nocturns are not just isolated actors. They’re a mesh.

RaptorCast is fully compatible with Ethereum’s consensus layer. It doesn’t alter finality or fork choice - it enhances communication.

This also makes Nocturns:

• Harder to isolate in eclipse scenarios
• Able to coordinate even with low-frequency slots
• Resilient to censorship and latency attacks

Public, permissionless, and already used in other coordination-sensitive contexts.

Economic Viability of Nocturn Slots

Lido controls over 30% of Ethereum’s stake, enough to propose ~1/3 of all blocks.
Even Vitalik Buterin has warned that no single entity should exceed 15% of total staking power.

Meanwhile, Titan Builder accounts for ~39% of Ethereum blocks. Some rescues require block-level coordination that cannot be achieved by auctioning bundles.

Nocturns offer a validator-native override path. When one of them is selected for a slot, it acts not for MEV - but for protection.

This avoids:

• Blind MEV auctions with 99.9% bribes fighting the scammer to rescue victims' funds
• Reliance on builder cooperation for rescue

Sometimes, the most effective move isn't a rescue - it's a refusal.

In scenarios where the scammer holds 99% of the bribe power, attempting to outbid is futile.
Instead, Nocturns offer a credible option:

• Seize what can be saved
• Burn what cannot be defended
• Send a message the chain won't forget

When rescue isn't viable, integrity still is.

This creates a new deterrence primitive:

• Scammers can't count on silence.
• Attackers know stolen funds may be publicly erased, not reabsorbed.

And it all depends on having the block.

To reach a reliable 3–5 minute cadence, the Nocturn registry must maintain:

• A distributed pool of standby validators
• Geographic and client diversity
• Sufficient stake allocation to consistently win slots

This requires incentivized coordination, sponsorship, or grants - not for profit, but for availability.

We are not asking for bribes.
We are asking for a defense budget.

If Ethereum can fund L2 scaling, it can fund L1 integrity.

---

Capital Requirements

Until we reach this critical mass, Nocturns will remain rare - but not useless.

Even with 1–5 blocks per day, a single well-timed Nocturn block can:

• Unfreeze funds in pig butchering cases
• Serve as a trusted checkpoint for intent-aware protocols
• Coordinate rescue execution across chains or DAO votes

A rare block is still a lifeline - when aligned.

But to move from exceptional interventions to predictable coordination, we must challenge the current validator monopoly.

Ethereum staking is not decentralized if 33% sits with a single LST cartel.

Our goal is not just to secure blocks - but to rebalance power:

• Bring neutrality back into the validator set
• Offer mission-driven staking as an alternative to passive LSTs
• Create a path for community-aligned defense capital to compete with liquidity-maximizing incumbents

To guarantee a consistent cadence of 1 Nocturn block every 3–5 minutes, we estimate the need for at least 32,000 ETH actively staked under Nocturn-aligned validators. This represents:

• Enough validator coverage to reliably win slots across the day
• Resilience against downtime or censorship
• A credible commitment to neutrality, with independently monitored behavior

These ETH deposits are not lost, not slashed, and not speculative - they serve the system by existing.

We propose:

• A dedicated treasury of 32k+ ETH locked under transparent governance
• An APR of ~5% redistributed to contributors (equivalent to normal staking yield)
• Fractional delegation mechanisms for smaller supporters (e.g., Nocturn shards, Killn support, rollup credits)
• Value scaling with ETH price, without reliance on inflation

This is not staking-as-a-service. It’s defense-as-a-layer.

Our Ask

1. Protocols:

   • Add optional gating logic to allow actions on Nocturn blocks.
   • Support visible markers or logs for Nocturn-aligned events.

2. Validators:

   • Join the Nocturn registry.
   • Accept to behave with transparent rationale during assigned slots.

3. Researchers:

   • Study survivability and griefing potential of Nocturns in live networks.
   • Help define thresholds for "intent clarity" (e.g., victim proof, DAO quorum, etc).

Appendix: When We No Longer Need Nocturns

There may come a day when:

• Protocols are fully intent-aware.
• Victim-proof logic is integrated natively.
• Slashing and governance disincentivize fraud proactively.

When that day comes, we will gladly shut down the registry.
Until then:

Ethereum doesn’t just need faster blocks. It needs braver ones.

---

03_nocturn_phylax_eigenlayer.md

Addendum 2: Phylax, EigenLayer, MEV-Boost and Defensive Interop

Purpose

This addendum explores the relationship and differentiation between Nocturns and adjacent security infrastructures - most notably Phylax and EigenLayer. While all three aim to harden Ethereum's defenses, their trust models, incentives, and timing assumptions differ.

---

Nocturns vs EigenLayer

Property	Nocturn	EigenLayer
Stake origin	Canonical ETH staking	Restaked ETH
Action trigger	Assigned slot by protocol	External contract call
Finality path	Ethereum-native	Smart-contract controlled
Time of awareness	≥6.4 min lookahead (epoch)	Often post-transaction
Value path	Defense-first, not profit-seeking	Yield-optimized, programmable risk

Summary: Nocturns are selected by Ethereum, for Ethereum. They do not opt-in to tasks. They are chosen, and react with coordination via lookahead. EigenLayer nodes accept opt-in assignments, often reactive, and may build marketplaces for security - but also inherit MEV-like profit maximization dynamics.

Ethereum chooses the Nocturn. EigenLayer lets you choose your mission.

---

Nocturns vs Phylax

Phylax introduces a model where shared security and programmable slashing allow off-chain actors to enforce on-chain outcomes - often in defense of bridge systems or rollup honesty.

Property	Nocturn	Phylax
Trigger mechanism	Protocol-granted block slot	External proof of misbehavior
Proof delay	None (pre-execution lookahead)	Post-event, sometimes days later
Scope of defense	L1 Ethereum native	Often L2/L1 bridge oracles
Slashing exposure	Minimal (unless malicious)	High, including social assumptions

Key Insight: Nocturns don’t slash. They defend in the moment, using a slot they did not ask for, but were given. Phylax operates more like a guardian - punishing after proof appears. They complement each other, but are not interchangeable.

---

Synergies

MEV-Boost Compatibility

Nocturns operate fully within the standard validator pipeline and remain compatible with MEV-boost and other builder-relay architectures.

However, when selected for a Nocturn slot, the validator may choose to:

• Reject all external builder payloads and submit a self-built rescue block
• Run a local relay prioritizing protective bundles or bribe-neutral execution
• Accept fallback bundles only if they meet intent-aware constraints

A Nocturn block doesn't bypass the builder - it overwrites the auction when defense requires it.

This preserves economic alignment in normal operation, but allows surgical overrides when trust or safety is at risk.

To be clear: only the rescue-relevant transaction set requires priority.

• Any remaining slot space - or full blocks when no rescue is active - can and should be filled through standard MEV-boost auction flows.
• This ensures that Nocturn validators continue to contribute to Ethereum’s economic throughput, not suppress it.

We are exploring a patch to MEV-boost that:

• Detects if the proposer is a registered Nocturn for the upcoming slot
• Enables partial builder integration: reserve for rescue txs, auction the rest
• Falls back to full builder payload if no intervention is declared

If no rescue is needed, the auction runs.
If a rescue only requires 3 transactions, the rest of the block is yours to auction.

1. Lookahead-to-Phylax alerting: If a Nocturn sees risk forming, it can relay this to Phylax-equipped chains.
2. Phylax bridge delay extension: Phylax can delay bridging when a Nocturn slot is known to be imminent.
3. Shared registry for aligned validators: Validators can dual-register under both roles, with transparency into dual commitments.

---

Conclusion

Nocturns do not replace EigenLayer or Phylax - they precede them.

They act when others wait.
They act when others react.

And they act with Ethereum’s own clock.

Because sometimes, defense must happen before finality.

04_nocturn_addendum3_ass_era.md

Addendum 3: Post Pectra and the Application-Specific Sequencing Era

Purpose

This addendum investigates how Nocturns interact with the rise of Application-Specific Sequencing (ASS), and what role they play in the context of EIP-4337 / EIP-7702 intent-centric Ethereum.

While Nocturns are not "sequencers" in the traditional app-specific sense, they offer a consensus-integrated backstop - a final protective override mechanism that operates across the entire slot, not just an app boundary.

---

Role of Nocturns in the ASS Landscape

Application-Specific Sequencers (ASS) optimize for:

• Order fairness
• MEV internalization
• User experience within their own state domain

But they do not protect against:

• Bribe-maximizing builder collusion
• Cross-app griefing
• Global block-level emergencies

That’s where Nocturns come in:

• ASS handles intra-app ordering
• Nocturns handle slot-level emergency override

Nocturns don’t displace application sequencers.> They rescue them - when coordination fails.

---

4337 and 7702: Intent-Centric Ethereum

EIP-4337 and EIP-7702 redefine how users interact with Ethereum:

• 4337 introduces UserOperations and a mempool for intent-based execution.
• 7702 lets a wallet temporarily become an EOA for arbitrary execution - often controlled by an external contract (e.g. drainer).

This opens a new class of rescue scenarios:

The victim is still onchain. But their signature path is hijacked.

Problem

• A 7702 wallet is temporarily controlled by a malicious implementation
• The attacker can forward all tokens out using delegated logic
• The real owner cannot override - unless they win an auction against a max bribe builder

Nocturn Role

When a Nocturn slot is upcoming:

• A pre-signed revoke() or rescue() tx from the victim can be loaded
• The Nocturn validator sees it before the builder auction starts (thanks to lookahead)
• It can force inclusion, even if the MEV logic would have censored it

This allows:

• A deterministic window for rescue (Nocturn-aligned apps can require it)
• A burn or safe redirection of the rest of the funds
• A narrative: Ethereum gave the user a chance to claw back control

In the age of programmable wallets, protection must be programmable too.

Nocturns become the last-resort sequencer for intent-locked victims.

---

Umbrella Protection via EIP-7251

With the introduction of EIP-7251, validators will be able to stake up to 2048 ETH per instance via validator merging.

Nocturn proposes an additional use-case for this capacity:

• Validators under threat, under coercion, or dissenting from cartel behavior can be absorbed into the Nocturn umbrella
• Their stake is merged, protected, and realigned with public rationale
• This creates an opt-in whitehat staking shell, able to defend itself while acting within protocol rules

In the case of validators whose withdrawal credentials or keystore access have been compromised, the umbrella also provides an optional escape path:

• The stake can be re-merged into a fresh validator, under community-coordinated rescue
• The compromised validator is exited on-chain and no longer able to propose
• Any residual ETH is either returned to the rightful owner, or burned in case of ambiguity

This expands Nocturn from a proposer-aligned actor to a stake-level shield in validator coordination.

Nocturn thus offers:

• A survival path for minority validators
• A legal, transparent alignment framework for staking dissent
• A scalable trust anchor up to 2048 ETH per protected validator
• A fallback mechanism for withdrawal key compromise events

Umbrella merging is not just about scale - it's about sovereignty.

05_nocturn_identity_addendum.md

Addendum 4: Validator Identity, Consent Proofs, and Trustworthy Nocturn Declaration

Problem: The Limits of block.coinbase and the Challenge of Prover Identity

Smart contracts sometimes rely on block.coinbase to infer the block proposer. But:

• block.coinbase is a writable field, not a verified fact
• It can be spoofed by any validator
• It cannot prove that a rescue condition is genuine or authorized

In a Nocturn setting, where a single slot can carry the weight of thousands of users or a major fund recovery, relying on block.coinbase is insufficient.

Trust must be anchored in cryptographic proofs, not assumptions about metadata

Any contract relying on block.coinbase == knownNocturn is vulnerable to spoofed proposer claims

---

Why This Matters for Nocturn

In rescue-sensitive contracts (unstaking, bridge releases, revocation flows), we want to encourage logic like:

import {Rescuable} from "@solady/Rescueable.sol";

contract AAVEv8 is Rescuable {
    function completeWithdrawStake() {
        if (RescueRegistry.isFlagged(msg.sender)) {
            require(
                NocturnRegistry.isActiveNow() &&
                block.timestamp > user.unstakingTime,
                "Wait for integrity checkpoint"
            );
        }
        // continue with normal withdrawal
    }
}

But unless that is anchored in real proposer identity, a malicious actor can:

• Set block.coinbase = some Nocturn address
• Trigger privileged behavior
• Drain or unlock under false assumptions

This breaks the entire assumption of block-level trust for app-integrated override.

---

Trustable Proposer Identity

The system should not rely on block.coinbase at all - instead, it must rely on the validator explicitly proving they are a Nocturn at the top of the block, using a verifiable signed transaction.

Instead, the recommended path is:

Nocturn-Originated Rescue Declaration (Top-of-Block TX)

• The validator selected for the Nocturn slot must publish a signed declaration transaction at the very top of the block

• This transaction proves:

  • That it comes from the rightfully expected slot proposer
  • That it is signed with the Nocturn key, or recognized in the NocturnRegistry
  • That it declares the slot as an active rescue window
  • That it includes a Merkle root of the rescue intents, or a reference to them

• The registry only activates if this transaction is:

  • Present in the block
  • Authenticated correctly
  • Aligned with precommitted or alliance-authorized rescue intents

• Without this tx, the registry remains inert. There is no way to spoof a Nocturn block without it, regardless of what is set in block.coinbase.

This tx is not optional. It is the anchor of override legitimacy.

Smart contracts interacting with this block can verify the presence and correctness of this declaration. If it’s missing or invalid, they must treat the slot as untrusted for rescue purposes - normal execution can continue, but no override logic should apply.

Alliance-Verified Delegation

• The rescue payload includes proof that each rescue was authorized by the whitehat alliance

  • Could be a multisig threshold proof
  • Could be a registry root snapshot

• This protects against unilateral abuse: even if the proposer is legit, each rescue must be pre-approved by the coalition

The Nocturn block begins with a declaration tx. Everything else flows from that commitment.

---

Optional Primitive: Canary Wallets and the Broken Wallet Signal (BWS)

Some users or protocols may opt-in to register a low-value public address known as a Canary Wallet - a small EOA intentionally placed in vulnerable infrastructure (such as Web2 repositories or CI secrets) as a honeypot signal for compromise.

• If the canary address sends funds or performs actions unexpectedly, specialized rescue searchers and validators detect the signal, verify its configuration, and flag the associated primary address in the RescueRegistry
• Contracts may reference this status and suspend withdrawals or delay sensitive actions
• Canary configurations are published through the same registry - no external oracle is needed

Canary wallets don’t protect funds. They protect reaction time.

When victims cannot publish explicit intents, due to surveillance, coercion, or loss of infrastructure, they may still signal consent cryptographically through a one-way irreversible action.

This is the essence of the Broken Wallet Signal (BWS):

• A compromised EOA signs two messages with the same ECDSA nonce (k reuse)
• This creates a cryptographic leak equivalent to apoptosis - a self-initiated, irreversible exposure to trigger cleanup
• Rescue searchers and validators - detect this signal, verify it, and anchor the identity into the RescueQueue

You can't fake apoptosis. Only the cell knows when to break - and Nocturns watch for the signal it leaves behind.

Two modes of BWS:

1. Public BWS (Last Resort)

• The double-signatures are visible onchain or offchain
• Sometimes, a BWS is the only way for a victim to sink their own ship - because they know the scammer is still onboard - and some more honest participants might swim faster than him
• Any actor can detect the key leak and submit a rescue intent on behalf of the victim
• Requires no trust - only observability
• Applies for validator rescues, stuck funds, compromised staking wallets

2. Private BWS (Encrypted or Delegated)

• The signal is encrypted or staged
• It is only revealed to a trusted Nocturn searcher or relayer
• Allows plausible deniability and timing control
• Can still be anchored through a declaration tx when the slot is secured

BWS is a final gesture. Not a request. A key, burned to prove that consent existed - even if voice could not.

On Noise and Seppuku Signals

Like all permissionless systems, BWS can be spammed. Nothing prevents a malicious or idle actor from leaking keys intentionally - or staging false cries for help.

It is also possible for an attacker to simulate a BWS using a stolen wallet, attempting to justify control over funds by leaking the key themselves. However:

• This gives the system a window to pause, park the funds, and wait for the real owner to come forward
• Rescue searchers may delay final execution if the context is ambiguous, and wallets could check registry status and initiate rebuttals

Thus, even if abused, BWS does not automatically transfer ownership - it creates an anchor of emergency visibility.

Meanwhile, inclusion in the RescueQueue does not guarantee prioritization. Nocturn searchers and alliance operators apply filters:

• The signal must correspond to a stake or meaningful balance
• The address should not be part of a known simulation pattern
• The RescueQueue may require offchain prevalidation or ranking by public bounty weight

And if attackers coerce users into BWS? They already trick people into seed phrase reveals. BWS just makes the signal observable - not irreversible.

In this model, rescuing someone requires more coordination than generating noise - but that asymmetry helps filter intent from randomness.

We don't assume every seppuku is sacred - but we still check for a pulse.

---

Optional Future Path: Proposer Identity Exposure via Precompile

We support the direction of EIP-7843 and similar proposals that aim to expose the real consensus-layer proposer to the EVM. This would take the form of a precompile or syscall:

address proposer = block.proposer; // future syscall

This capability would:

• Fully remove the spoof risk of block.coinbase
• Allow smart contracts to verify proposer-based constraints natively
• Make onchain trust logic simpler and more auditable
• Remove dependency on offchain registry lookups or commitment anchors

However, we emphasize: this is not required to deploy Nocturn today.

Everything needed for secure override can be done now:

• A top-of-block declaration tx signed by the validator
• Rescue payloads verified by alliance-level authorization (e.g. multisig or Merkle proof)
• Smart contracts reacting only when a valid declaration is present

---

Reactions and Adversarial Response

Once this system exists, some actors may adapt:

• Monitoring the Nocturn registry to anticipate override windows
• Attempting to frontrun or grief rescue payloads
• Rejecting rescue txs selectively

But the presence of a signed top-of-block declaration makes responses observable:

• Protocols that acknowledge rescue slots can align proactively
• Those that ignore or reject them may signal deeper misalignment

Nocturn doesn’t force trust - it creates clarity around who aligns with intent.

06_nocturn_addendum_5_dv_tool.md

Addendum 5: Nocturn, Obol, TOOL, and the Trillion-Dollar Security Layer

Context

Ethereum is preparing for a future where:

• Validators are no longer solo agents but distributed clusters (Obol DVs)
• The mempool and builder pipeline is partially offchain, TEE-based, or intent-driven (TOOL, SUAVE, others)
• Smart contract access flows are managed by EIP-7002, 7685, and other execution-triggerable systems
• Ethereum’s trust surface must handle trillions of dollars of security-sensitive value

Nocturn aligns with this future as a validator-layer override framework, able to insert guardrails at the proposer level regardless of what builder or solver logic precedes it.

---

How Nocturn Complements Obol DVs

Obol enables fault-tolerant, multi-operator validators (DVT). Nocturn strengthens their rescue sovereignty:

• A DV cluster can jointly agree to a rescue slot using threshold logic
• The RescueDeclarationTx can be signed by a shared DV consensus or quorum
• This allows Obol-based validators to act as a single Nocturn, but with distributed governance

Synergy: Obol gives resilience to operation; Nocturn gives integrity to intervention.

Together, they form a neutral, defensible validator class.

---

How Nocturn Connects to TOOL

TOOL slices blocks into 12 × 1s windows, runs sealed-bid auctions, and uses TEEs for orderflow privacy.

Nocturn integrates at the proposer level - it does not disrupt TOOL’s sequencing, but adds a final integrity checkpoint at the slot level:

• TOOL may win the auction
• But Nocturn can still publish a top-of-block signed override declaration
• This declaration anchors rescue legitimacy, regardless of offchain mempool or TEE mechanics

Now imagine:

• A rescue block where the searchers must compete to include their bundle
• But strapped with a victim-proof constraint - as if each bid carried an injured child on their back
• A TOOL mini-block sealed at 1s cadence, with one bundle reserved for justice

This is not just about speed - it’s about bounded correctness.

Nocturn does not slow TOOL down. It enfolds seamlessly into its flow, adding structural guarantees without friction.

Conclusion: TOOL optimizes intent execution; Nocturn guarantees fallback justice - without blinking.

---

EIP Alignment: Execution-Layer Triggerable Logic

EIPs like:

• EIP-7002: Execution-layer exits
• EIP-7685: General EL triggered messages

enable smart contracts to act conditionally on proposer actions or block contents.

Nocturn can act as the activator:

• Without EIP-7685, contracts read RescueDeclarationTx directly and verify proofs onchain
• With EIP-7685, a formal message (e.g., NocturnDeclaration) can be emitted as part of the EL→CL message set

This creates a dual track model:

1. Deployable now:

   • Rescue txs and override logic function based on transaction presence and signature
   • No new syscall or EVM semantics required

2. Upgradeable later:

   • EIP-7685 standardizes this declaration into a native trigger
   • Contracts can subscribe to block.trigger("NocturnDeclaration")
   • This enables rescue-aware logic without relying on calldata parsing or intent trees

Nocturn is compatible with today’s execution model - and future-ready for tomorrow’s trigger layer.

---

Rescue Queue, Ranking, and Fairness

As Nocturn slots gain adoption, new challenges emerge:

• What happens when more rescues are valid than can fit in a single 30M gas block?
• How should we prioritize victims fairly?
• How do we handle interdependent rescues - where rescue1 enables rescue2, or breaks it?

This leads to a needed structure: the RescueQueue.

RescueQueue Principles

In the long term, the queue can be made ZK-verifiable - turning rescue arbitration into a public proof system. This ensures that the order and inclusion of rescue intents cannot be manipulated, and no victim can be silently deprioritized.

1. Explicit Queue Commitment

   • Intents are pre-registered by alliance actors, with proof-of-victim or signed UserIntent
   • Each queue entry includes metadata such as: when it was submitted, which slot it's aiming for, whether it depends on other rescues, and how strong its verification backing is

2. Conflict-Aware Ordering

   • If two rescues are mutually exclusive, the validator must detect it and choose based on preset scoring
   • Dependency failures are anticipated before inclusion

3. MEV-aware fairness

   • If a rescue tx gets displaced for gas cost, any value recovered must be partially redirected to the displaced entry
   • “Saving victims” becomes a solvable optimization - not just first-come, first-mev’d

4. Searchers-as-Rescuers

   • Builders or solvers can compete to include rescue bundles if they preserve declared order
   • Ranking is not just gas price - it’s contribution to confirmed rescue resolution

5. Time-based batching

   • Alliances can delay minor rescues to bundle 100+ in a single block if needed
   • Fairness is evaluated across the full rescue effort - not just tx-by-tx inclusion

The RescueQueue is not just a pipe. It’s a contract of mutual prioritization.

---

Toward a Nocturn-Aware Layer One

The Ethereum Foundation’s Trillion Dollar Security Project makes clear:

"Companies, institutions, and governments must feel safe storing $1T+ in a single contract or application"

But this future is not only about large institutions - it is also about millions of individuals who must feel confident holding savings, identities, and rights onchain.

Nocturn answers this need at both ends of the spectrum:

• It does not replace neutrality - it operationalizes it
• It does not assume compromise - it demands proof
• It does not break protocol - it uses the slot Ethereum already gives

From a solo staker defending their validator against a key compromise, To a rescue orchestrator saving thousands of wallets in a single override, To a whitehat queue accumulating rescue payloads for a future coordinated slot -

The logic is the same:

If Ethereum wants to secure a trillion, it must secure the edge. And that means enabling selective, verifiable overrides - without requiring forks or compromise.

Ethereum's L1 does not need complexity creep. It needs clarity of role:

• A slot for sovereignty (Nocturn)
• A queue for justice (RescueQueue)
• A contract of neutrality that holds, even under stress

And all of it designed - as Vitalik frames it - to be credibly neutral, provable, and, above all, simple enough to survive.

Privacy is order. Neutrality is proof. Simplicity is resilience. Nocturn may not be the final layer - but it offers the coordination shell that helps hold them together.

07_addendum_6_explorations.md

Addendum 6: Explorations Toward a Resilient Nocturn Layer

Overview

Ethereum continues to suffer measurable losses from scams, drains, and interface betrayals - not because it lacks the tools to act, but because it lacks the coordination layer to act deliberately.

This addendum exists as a reminder: the alternative to these mechanisms is not some clean baseline of neutrality. The alternative is silence, paralysis, and routine loss.

Nocturn is not an escalation. It is the memory of what was tolerated too long.

This addendum documents the next phase of evolution for Nocturn. While Addenda 1–5 have laid out the operational core (proposer identity, declaration TXs, builder overwrite logic, registry checks…), this document captures the outer perimeter - what must emerge if Nocturn is to become not just a validator override, but a coherent security shell for Ethereum.

Some mechanisms are near-term (e.g. MissRegistry). Others are speculative, yet increasingly necessary in a post-Pectra, DV-heavy landscape. These explorations represent the frontier where rescue logic meets staking architecture, validator coordination, and social legitimacy.

---

1. NocturnMissRegistry: Verifiable Miss Tracking

Problem

When a validator is scheduled to propose a Nocturn block (with a known rescue intent available), but fails to include the required declaration transaction, the rescue intent is lost. Worse, this failure may remain silent - no slash, no trace, no feedback loop.

Goal

Create an onchain registry of verifiable "misses" by Nocturn validators. Anyone can publish a record that proves a slot was missed despite:

• The slot being assigned to a registered Nocturn
• A valid rescueRoot being known in advance
• A declaration signature being publicly expected

Specification (Sketch)

function reportMiss(
  uint256 slot,
  bytes32 expectedRescueRoot,
  bytes calldata declarationSig,
  bytes calldata proposerProof
) external {
  require(!wasDeclared(slot), "Declaration found");
  require(isValidRescueRoot(expectedRescueRoot), "Unknown rescue root");
  require(verifyProposer(slot, declarationSig), "Invalid declaration sig");

  misses[slot] = MissedRescue({
    slot: slot,
    rescueRoot: expectedRescueRoot,
    reporter: msg.sender,
    timestamp: block.timestamp
  });

  emit MissRegistered(slot, expectedRescueRoot, msg.sender);
}

Implications

• Creates accountability for passive failure
• Enables governance decisions (revocation, delegation changes)
• Provides UX feedback ("rescue missed due to proposer omission")
• Can be extended into slashing or downgrade signals

---

2. Partial Payload Auctioning with Rescue Priority

In most cases, a rescue will only occupy the first 1–3 txs of a block. Rather than requiring validators to forfeit MEV income or disable their builder pipeline, we propose a hybrid auction structure:

• If DeclarationTX is present → reserve top N tx slots for rescue
• Remaining gas is auctioned via MEV-Boost
• Builders aware of RaptorCast signals can pre-adapt

Benefits:

• Rescues retain atomic priority
• Validator economics remain healthy
• Builder cooperation becomes opt-in, not mandatory

This model assumes either full block overwrite or builder cooperation. No native interface yet reserves a rescue segment - but layering on top is viable.

If future builder stacks (like TOOL or SUAVE-style programmable relays) allow transaction stream hints or partial overwrite zones, this integration may become first-class.

---

3. App-Level Rescue Filters (DAO-Aware Interface)

Not all protocols want to automatically act on a Nocturn block - even if it's validly declared.

Many DeFi protocols are governed by DAOs with formal proposal/vote/queue/execute cycles - often managed through tools like Snapshot, Tally, or OpenZeppelin Governor. These protocols may require:

• Onchain DAO vote to approve a rescue intent
• Explicit queueing or delay period before unlock
• Offchain quorum attestations tied to rescueHash

Proposed Interface:

interface RescuePolicy {
  function acceptsIntent(bytes32 rescueHash, uint256 slot) external view returns (bool);
}

This interface lets a protocol encode its logic for when a rescue becomes legitimate. For example:

function acceptsIntent(bytes32 h, uint256 slot) external view override returns (bool) {
  return governor.hasQueued(h) && slot >= queuedBlock + 1;
}

Or:

function acceptsIntent(bytes32 h, uint256) external view override returns (bool) {
  return snapshotVotes[h] > VOTE_THRESHOLD;
}

This approach:

• Respects governance sovereignty
• Integrates cleanly with DAO tooling
• Makes rescue alignment observable onchain

No rescue is forced. But once acknowledged, it carries weight - and often, consequence.

---

4. Umbrella Merge & EIP-7251

Context

With the arrival of Pectra and EIP-7251, Ethereum now supports validator consolidation up to 2048 ETH. This allows stake and operational power to be grouped into larger, more coherent validator instances.

For Nocturn, this opens two critical paths:

4.1 Nocturn Umbrella

• Minority validators can merge into a shared DV cluster running Nocturn logic
• Allows for stake rehabilitation (e.g. leaked withdrawal credentials)
• Provides shared infrastructure with public-good guarantees

This turns Nocturn into more than a coordination layer - it becomes a staking umbrella capable of absorbing and realigning dissenting or vulnerable actors.

4.2 Migration Mechanism

• Pectra allows stake movement without key rotation
• This enables safer reallocation of stake toward Nocturn-aligned validator clusters
• Compatible with Obol-style DVs and DKG for slashing resistance

---

5. Anti-Capture Guarantees (WIP)

As Nocturn influence grows, so does the risk of capture - whether cartel-based, governance-based, or grief-based. We propose future-proof hooks:

• NocturnMissRegistry can track silent failure over time
• Multi-sourced declaration signing (co-sign or 2-of-N)
• Public RaptorCast logs for rescues declared but not included
• Optional re-routing: if proposer fails, next Nocturn picks up declared root

---

6. Guardrails Against Rogue Rescue Payloads

Not every declaration proves alignment. A rogue validator can sign a valid top-of-block transaction and still include a malicious payload. Identity proves authorship - but only intent proves legitimacy.

Problem

What if a rogue validator proposes a block with a declaration transaction and valid-looking rescue intent, but the payload is malicious - e.g. draining an entire protocol, front-running a known vulnerability, or faking a victim?

Defensive Options:

1. App-Side Acknowledgment

   • Protocols that adopt RescuePolicy interfaces can choose to reject payloads onchain if they don’t match expected governance or intent rules.

2. Intent Registry Commitments

   • Each rescueRoot should point to a registry-published Merkle tree, backed by signatures from a recognized rescue council or multisig quorum.

3. Slot-Scoped Rate Limiting

   • Contracts may enforce per-slot or per-block action limits (e.g. onlyOneEmergencyUnlockPerBlock())

4. Post-Rescue Transparency Layer

   • Every rescue intent should be auditable post-inclusion, and registered in a canonical feed (e.g. onchain IPFS hashlog or ENS anchor)

5. Temporal Friction for Critical Assets

   • Even when a rescue is accepted and validated, smart contracts may wish to introduce a soft delay before final funds are transferred.
   • Instead of calling unlock() immediately, the rescue logic can write a `` state with metadata (slot, hash, timestamp), allowing actual release to happen in the next block or two.

Example Implementation (Solidity)

struct RescuePending {
  address target;
  uint256 rescueSlot;
  uint256 delayBlocks;
  bool confirmed;
}

mapping(bytes32 => RescuePending) public pendingRescues;

function declareRescue(bytes32 rescueHash, address victim) external onlyValidator {
  pendingRescues[rescueHash] = RescuePending({
    target: victim,
    rescueSlot: block.number,
    delayBlocks: 2,
    confirmed: false
  });
}

function finalizeUnlock(bytes32 rescueHash) external {
  RescuePending storage r = pendingRescues[rescueHash];
  require(block.number >= r.rescueSlot + r.delayBlocks, "Unlock still pending");
  require(!r.confirmed, "Already executed");

  r.confirmed = true;
  _releaseFunds(r.target);
}

This allows external actors (watchdogs, DAOs, fallback validators) to observe the slot and, within a 2-block delay, signal cancellation, burn, or alternate redirect if the rescue is later proven malicious.

It may sound tedious - but it's better than letting the scammer win by default. The delay is short, the risk is real, and the cost of inaction is measurable.

Every scam left unchallenged becomes precedent. Every rogue validator ignored becomes an invitation.

We don't do this because it's convenient. We do it because not doing it guarantees loss.

This isn’t a stall. It’s a window. A controlled breathing room, where Ethereum remembers to verify, not just react.

These guardrails preserve the speed of intervention for genuine rescues, while giving apps and users a chance to verify alignment, and slow down or deny hostile actors masquerading as whitehats.

---

Reminder: The L2s Are Laughing

Neutrality is often misused to justify inaction. If a system cannot be perfectly neutral, some argue it should not act at all. But this narrow-sense neutrality - purity by paralysis - undermines broader neutrality by enabling exploitation.

Ethereum must move beyond the illusion that doing nothing is always safer. Sometimes, coordination is the only neutral thing left.

Rollups today have circuit breakers, escape hatches, multi-sig backdoors, and admin pausability baked into their core. They can act - whether it's to freeze, unwind, or refund. Sometimes that power is abused.

But often, it's used. Deliberately. Fast.

Meanwhile, Ethereum L1 - the layer entrusted with global neutrality - flinches. It stalls. It lets victims wait for years while griefers rotate wallets.

L2s are laughing at us - not because we lack the tools, but because we refuse to coordinate them.

We can do better. And Nocturn is that attempt.

Execution must remain neutral - but not silent.

And scammers must lose.