Introduction

We’re thrilled to announce that the Decentralized Infrastructure Network (DIN) has successfully completed ephemeral testnet v0.1, bringing together nine DIN Providers in a multi-stakeholder effort across EigenLayer, AltLayer, Buildbear, and Txtx. This milestone demonstrates the viability of DIN’s approach to onboard staking/slashing rewards into the existing DIN decentralized RPC infrastructure. DIN is live and actively decentralizing Infura and MetaMask, but the DIN AVS initiative actively tests the security/economics of the ecosystem withEigenLayer’s new slashing mechanism.

Below, we’ll dive into what this testnet set out to prove, the lessons learned, how slashing helps build trust with EigenLayer Operators, and how we’re gearing up for more tests on our way toward mainnet.

Why DIN as an AVS?

DIN’s Autonomous Verifiable Service (AVS) provides a straightforward, on-chain mechanism to onboard and oversee Node Providers, enforce SLAs, and reward Watchers for high-quality monitoring—all without manually policing performance. By anchoring DIN’s provider “allow list,” test flows, and penalty logic in an AVS, we unify the economic and operational incentives: Node Providers stake capital (ensuring commitment to uptime and correct data), while Watchers confirm performance (and can trigger jailing or slashing for repeated failures). This autonomous “watchtower” design cuts out the overhead of one-off checks, enabling DIN to scale its multi-chain RPC marketplace with stable reliability and transparent governance.

Why an “Ephemeral Testnet”?

DIN as an AVS was tested on a fork of Holesky testnet (due to issues with finalization during the Petra upgrade) using the BuildBear tech stack. The “ephemeral” portion of the testnet is mostly for the security of any of the wallet identities created for the runbook testing. The DIN AVS Testnet v0.1 ran from February 27, 2025, to March 26, 2025, on a fork of Holesky with testing of EigenLayer operator registration, allowlist approval, and operator set onboarding.

For transparency, note that all DIN Providers that were tested will be subsidized with future mainnet staking amount for one operator set.

Using BuildBear in a pinch

The DIN team leveraged BuildBear sandboxes to create a stable and collaborative environment for rigorously testing each iteration of the protocol. While the Holesky Pectra upgrade posed challenges that might have derailed timelines, the infrastructure proved resilient. As one developer noted, "BuildBear being up during the Holesky holdup allowed us to continue unimpeded."

Paired effectively with Txtx runbooks, the setup enabled a safe, repeatable, and highly reliable deployment process. The team could swiftly deploy an entire test version of the protocol, easily sharing it with all relevant stakeholders for comprehensive review. For DIN, with its diverse and broad stakeholder group, the social and collaborative aspect of this workflow proved invaluable. Utilizing this integrated toolset to systematically execute transactions and generate detailed reports allowed operators and developers to identify and resolve anomalies collectively.

DIN’s lead protocol developer, Amal Sudama, emphasized the significance of these tools, stating, "BuildBear and Txtx together have dramatically accelerated our development velocity. The composition of Txtx and Buildbear feels like we’ve unlocked a superpower for building confidence as we manage development and launch risks. We look forward to using BuildBear's CI system and sequence diagrams to further accelerate our smart contract development."

A 9-Provider Collaboration

Over the course of this v0.1 ephemeral testnet, nine DIN Providers collaborated on validating our AVS operator onboarding and approvals workflow. Thanks to close coordination with dev teams from EigenLayer, AltLayer, Buildbear, and Txtx, we tested end-to-end flows covering:

• Operator Registration and Approvals – Checking that each provider could register as an AVS operator under different software configurations.

• Operator Set Testing – Demonstrating how providers joined specific EigenLayer operator sets for DIN, then performed the required on-chain steps to confirm proper membership.

• Runbook‑Based Debugging – Each team relied on ephemeral runbooks to walk through tasks like verifying contract addresses, capturing logs, and ensuring transaction correctness.

Community & Ecosystem Support

These nine providers, along with our ecosystem partners, invested time in troubleshooting unexpected edge cases. That effort helped refine ephemeral runbooks and bring clarity to terms, definitions, and usage flows. We deeply appreciate their dedication and candid feedback, which will inform future improvements.

Building Trust: EigenLayer’s Slashing Feature

When an infrastructure provider’s performance directly affects its staked collateral, quality of service becomes an economic necessity. DIN chose to implement the EigenLayer’s slashing feature through a tiered penalty system in order to ensure Node Providers are incentivized to operate at peak reliability. At the same time, Watchers stake tokens to back their monitoring activity in order to prevent any risky dishonest or contradictory claims.

• Stake-Backed SLAs - Node Providers work with EigenLayer operators to stake collateral to guarantee consistent uptime, valid data responses, and quick failover if issues arise. If they fail, the AVS can enforce slashing based on severity.

• Data-Backed Enforcement - To determine who gets slashed, DIN relies on Watchers, specially designated nodes that continuously test Node Providers endpoint availability, data correctness, and latency. If a Watcher detects consistent underperformance, it can submit evidence to the DIN AVS, which triggers penalties or “jailing” until the problem is resolved. Watchers themselves must also stake capital to remain honest and accurate.

• A Fair Appeal Process - DIN avoids heavy-handed punishments by allowing Providers to dispute Watchers’ claims. A short challenge period and a small veto committee let them present logs or proof to correct misdiagnoses. If validated, their stake is refunded and reputational harm is reversed.

• Multi-Watcher Redundancy - DIN’s approach includes launching multiple Watchers across diverse operators. This guards against single points of failure or collusion among watchers. By expanding the set of watchers, DIN reduces centralization, ensures better coverage, and keeps verifications genuinely decentralized.

Lessons Learned & Observed Patterns

1. Software & Signer Diversity - We discovered that operators come with various operating systems, key-management tools, and CLI preferences. Future runbooks need to be simpler for non‑Unix platforms, and we’ll optimize onboarding scripts so Windows-based operators can proceed smoothly.

2. Value of Verified Contracts - Multiple participants noted the importance of having contract addresses verified on Etherscan with real-time logs/events visible. This clarity reassures operators that each state change is accurate and fosters trust in the AVS architecture.

3. Streamlined Checklists - Early feedback revealed that some onboarding steps felt confusing or repetitive. For the next ephemeral iteration, we’ll reorganize the runbooks and add clearer definitions of DIN/AVS terms. This ensures everyone (especially first‑time operators) can follow along without guesswork.

4. Operator Set Validation - Despite the ephemeral nature of this test, we successfully confirmed that the DIN‑extended EigenLayer middleware handles operator sets as expected. This validation paves the way for deeper staking and slashing scenarios in the subsequent phases.

5. Runbooks + Real-Time Logs - Capturing every contract interaction event was crucial. Publishing these events and logs as part of each step made it easier for operators to verify their progress. Building on that success, we’ll further integrate logs into future runbooks to provide an even more transparent experience.

6. Path Toward Testnet 0.2 - Based on these insights, our next ephemeral run will emphasize improvements in “flows,” validation logic, and how signing steps are communicated. We want Node Providers and Watchers alike to feel the process is both simpler and more robust at every stage.

Roadmap: Ephemeral Tests, More Providers, Path to Mainnet

Ephemeral Testnet v0.2 has already kicked off. This is first being tested with our internal DIN Providers that are already running as Node Providers for Infura and MetaMask RPC traffic. We will open conversations to gain EigenLayer Operator interest in the coming quarter.

Our immediate next steps are to:

1. Publish a Cumulative Report on testnet results, comparing throughput metrics, slashing incidents, and average node response times.

2. Begin Finalizing Mainnet Parameters (e.g. token distribution, AVS staking thresholds, Node Provider licensing approaches).

Once these ephemeral cycles demonstrate stable and reliable cross-system updates, we will shift into additional edge case testing, smart contract audits, and mainnet readiness. That includes verifying economic sustainability of node operators, watchers, and ensuring smooth governance transitions.

How to Get Involved

Stay tuned for more exciting updates, and don’t forget to follow us on our new social channels (DINBuild on X, Mirror.xyz, and YouTube) to stay informed. Learn more about DIN on din.build.