DV8 has completed its first capital raise since undergoing a strategic shift toward becoming Southeast Asia’s first crypto treasury company, securing approximately THB 241 million (roughly $7.4 million), according to a filing released July 16.

The funding round closed with a 99.9% warrant exercise rate, marking a critical vote of confidence from existing shareholders in the firm’s long-term Bitcoin-native model.

The raise resulted in 301,491,057 new shares issued from the exercise of DV8-W2 warrants, at an exercise price of 0.80 baht per share. The remaining unexercised warrant total stood at just 345,930 units. DV8 reported a 38% growth in its cash treasury and a 13% increase in yield per share following the round.

Who is DV8?

DV8’s board has previously signaled its intention to replicate Strategy-style corporate finance strategies centered around Bitcoin accumulation and digital asset-backed value creation. The firm’s treasury model is aligned with the broader pivot led by a regional consortium of crypto-focused investors, including Metaplanet, Sora Ventures, Kliff Capital, and others, which recently acquired the Thai-listed electronics and retail company through a voluntary tender offer.

Metaplanet, the Tokyo-based public firm that emerged as one of the world’s largest corporate Bitcoin holders following its own treasury conversion, has become a guiding reference point for DV8’s transition. The Japanese company’s stock rose by over 11,000% across its treasury pivot, reinforcing the appeal of this strategy among firms exploring alternative financial models in Asia.

DV8’s transformation is also driven by a leadership overhaul led by Thai businessman Chatchaval Jiaravanon, known internationally for acquiring Fortune Magazine. His appointment as chairman was part of a broader board reshuffle aimed at repositioning DV8 as a crypto-financial infrastructure firm targeting Southeast Asian markets.

Recent moves by the consortium, such as the acquisition of Seoul-based SGA Co. to support new digital asset ventures, signal coordinated efforts to institutionalize crypto treasury adoption across the region. The investors have highlighted their interest in expanding into the Philippines, Vietnam, Indonesia, and Malaysia by partnering with execution-ready local firms.

The THB 241 million raise represents the first major liquidity infusion into DV8 since its crypto pivot and will be used to accelerate its operational transformation. According to the company, the capital sets the foundation for executing its long-term digital asset strategy and serves as a template for future funding rounds tied to treasury expansion.

Mentioned in this article

Blockchain sharding, worded in the most succinct way possible, is the division of network activity into smaller, more manageable parts, to enhance performance and scalability. Execution sharding, more specifically speaking, involves breaking down the execution of smart contracts into smaller, more efficient pieces. Tahir Mahmood, co-founder of KRNL, and kOS, the company’s flagship product, are disrupting the execution sharding landscape with a fresh, innovative, and breakthrough approach

Should KRNL’s approach genuinely differ from traditional methods, such as data sharding, network sharding, and other approaches to execution sharding, it would prove critical to the future of dApps.

Sharding in Web3

Execution sharding is typically done using co-processors or separate environments, which can introduce inefficiencies and centralization issues. “Currently, the way people implement the equivalent of execution sharding is they tend to do it from the wallet level, or a different layer and different network altogether, as a way of managing the execution,” Tahir explains. “What we’re doing within KRNL is happening natively on the node, so that way it’s part of the standard transaction flow. It’s not a separate network, and it’s not a separate environment.”

People currently consider execution sharding to be tied to co-processors, which are dedicated environments. KRNL has an alternative approach, Tahir explains, “What we’re doing is we’re bringing the concept that all these layer ones and layer twos with all this functionality built on them, can be exposed without having to create unique specific environments, which is actually what co-processors are,” Tahir adds.

KRNL’s breakthrough solution

KRNL’s approach to execution sharding is fundamentally different from others looking to solve the sharding dilemma.

“Some protocols and projects are sharding at the consensus layer of the blockchain. Others are doing it as a proxy layer in front-end of the wallet but this places it outside of the native Ethereum architecture. This leads to a solution that lacks critical security,” Tahir explains. “We are taking a different approach by doing it natively on the node. This is a best-of-both-worlds scenario, making you natively part of the transaction flow, while allowing you to run computation pre-transaction with the requisite security.”

This approach allows KRNL to create a more efficient and secure system with kOS. Tahir states that

“We’re creating something that is much more than co-processors, which are dedicated environments. What we’re doing is exposing the functionality on different chains without having to create unique specific environments.”

kOS is being dubbed the “Superconnector”, offering app builders frictionless access to functions natively on the chain, making it inherently different from the existing suite of execution sharding solutions on the market. Unlike what LayerZero (LZ) does for assets, KRNL’s Superconnector makes boundless functionality available anywhere and by anyone, but with a more decentralized and secure approach. This ensures that application builders can access and utilize functions across different chains with minimal overhead, enhancing both performance and security.

Taking execution sharding omni-chain

KRNL’s long-term vision, Tahir shares, is to create a holistic ecosystem that enables developers to build truly decentralized applications without the inefficiencies and centralization issues that come with co-processors and other existing solutions. Thus, by enabling the execution of functions across multiple chains, KRNL is paving the way for more efficient and secure dApp development.

“We’re able to utilize the whole plethora of all those environments natively as they are, without having to do the heavy lifting to create something that is unique and specific as a co-processor,” Tahir notes.

KRNL’s Superconnector, kOS, is a reimagining of how execution sharding should be implemented. By enabling frictionless access to functions natively on-chain, KRNL breaks down all barriers to omni-chain dApp building. Make note, this is a game-changer for worldwide, democratized, and streamlined dApp developments. Even more importantly for developers, they will be able to register and monetize the features they create on KRNL’s upcoming marketplace.

Tahir & KRNL’s Future Vision

Tahir aims to expand KRNL technology from Ethereum to other EVM and non-EVM chains, creating a holistic ecosystem. “We see developers and builders being able to build feature-rich real-world applications with very little work, almost no code, and low-code solutions,” Tahir states.

This approach will allow developers to build more robust applications more quickly and efficiently.

“You’re now able to say, ‘I want to do XYZ on chain and off chain in the Web2 world,’ because that’s what really brings real-world applications to life,” Tahir adds.

KRNL’s innovative approach to execution sharding through the Superconnector will redefine how we think about decentralized applications. The future of execution sharding lies in KRNL’s natively on-chain approach, which is set to revolutionize the Web3 landscape, making real-world applications more accessible and robust.

Mentioned in this article

Blockchain sharding, worded in the most succinct way possible, is the division of network activity into smaller, more manageable parts, to enhance performance and scalability. Execution sharding, more specifically speaking, involves breaking down the execution of smart contracts into smaller, more efficient pieces. Tahir Mahmood, co-founder of KRNL, and kOS, the company’s flagship product, are disrupting the execution sharding landscape with a fresh, innovative, and breakthrough approach

Should KRNL’s approach genuinely differ from traditional methods, such as data sharding, network sharding, and other approaches to execution sharding, it would prove critical to the future of dApps.

Sharding in Web3

Execution sharding is typically done using co-processors or separate environments, which can introduce inefficiencies and centralization issues. “Currently, the way people implement the equivalent of execution sharding is they tend to do it from the wallet level, or a different layer and different network altogether, as a way of managing the execution,” Tahir explains. “What we’re doing within KRNL is happening natively on the node, so that way it’s part of the standard transaction flow. It’s not a separate network, and it’s not a separate environment.”

People currently consider execution sharding to be tied to co-processors, which are dedicated environments. KRNL has an alternative approach, Tahir explains, “What we’re doing is we’re bringing the concept that all these layer ones and layer twos with all this functionality built on them, can be exposed without having to create unique specific environments, which is actually what co-processors are,” Tahir adds.

KRNL’s breakthrough solution

KRNL’s approach to execution sharding is fundamentally different from others looking to solve the sharding dilemma.

“Some protocols and projects are sharding at the consensus layer of the blockchain. Others are doing it as a proxy layer in front-end of the wallet but this places it outside of the native Ethereum architecture. This leads to a solution that lacks critical security,” Tahir explains. “We are taking a different approach by doing it natively on the node. This is a best-of-both-worlds scenario, making you natively part of the transaction flow, while allowing you to run computation pre-transaction with the requisite security.”

This approach allows KRNL to create a more efficient and secure system with kOS. Tahir states that

“We’re creating something that is much more than co-processors, which are dedicated environments. What we’re doing is exposing the functionality on different chains without having to create unique specific environments.”

kOS is being dubbed the “Superconnector”, offering app builders frictionless access to functions natively on the chain, making it inherently different from the existing suite of execution sharding solutions on the market. Unlike what LayerZero (LZ) does for assets, KRNL’s Superconnector makes boundless functionality available anywhere and by anyone, but with a more decentralized and secure approach. This ensures that application builders can access and utilize functions across different chains with minimal overhead, enhancing both performance and security.

Taking execution sharding omni-chain

KRNL’s long-term vision, Tahir shares, is to create a holistic ecosystem that enables developers to build truly decentralized applications without the inefficiencies and centralization issues that come with co-processors and other existing solutions. Thus, by enabling the execution of functions across multiple chains, KRNL is paving the way for more efficient and secure dApp development.

“We’re able to utilize the whole plethora of all those environments natively as they are, without having to do the heavy lifting to create something that is unique and specific as a co-processor,” Tahir notes.

KRNL’s Superconnector, kOS, is a reimagining of how execution sharding should be implemented. By enabling frictionless access to functions natively on-chain, KRNL breaks down all barriers to omni-chain dApp building. Make note, this is a game-changer for worldwide, democratized, and streamlined dApp developments. Even more importantly for developers, they will be able to register and monetize the features they create on KRNL’s upcoming marketplace.

Tahir & KRNL’s Future Vision

Tahir aims to expand KRNL technology from Ethereum to other EVM and non-EVM chains, creating a holistic ecosystem. “We see developers and builders being able to build feature-rich real-world applications with very little work, almost no code, and low-code solutions,” Tahir states.

This approach will allow developers to build more robust applications more quickly and efficiently.

“You’re now able to say, ‘I want to do XYZ on chain and off chain in the Web2 world,’ because that’s what really brings real-world applications to life,” Tahir adds.

KRNL’s innovative approach to execution sharding through the Superconnector will redefine how we think about decentralized applications. The future of execution sharding lies in KRNL’s natively on-chain approach, which is set to revolutionize the Web3 landscape, making real-world applications more accessible and robust.

Mentioned in this article

tl;dr

• EELS is an execution layer reference implementation in Python.
• It’s up to date with mainnet.
• It fills tests, and passes existing ones.
• There’s an example of an EIP implemented in EELS below.

Introduction

After more than a year in development, we’re pleased to publicly introduce the Ethereum Execution Layer Specification (affectionately known as EELS.) EELS is a Python reference implementation of the core components of an Ethereum execution client focused on readability and clarity. Intended as a spiritual successor to the Yellow Paper that’s more programmer friendly and up-to-date with post-merge forks, EELS can fill and execute state tests, follow mainnet¹, and is a great place to prototype new EIPs.

EELS provides complete snapshots of the protocol at each fork—including upcoming ones—making it much easier to follow than EIPs (which only propose changes) and production clients (which often mix multiple forks in the same codepath.)

History

Beginning in 2021, as a project of ConsenSys’ Quilt team and the Ethereum Foundation, the eth1.0-spec (as it was known then) was inspired by the sheer frustration of having to decipher the cryptic notation of the Yellow Paper (Figure 1) to understand the specific behavior of an EVM instruction.

Drawing on the successful Consensus Layer Specification, we set out to create a similar executable specification for the execution layer.

Present

Today, EELS is consumable as a traditional Python repository and as rendered documentation. It’s still a bit rough around the edges, and doesn’t provide much in the way of annotations or English explanations for what various pieces do, but those will come with time.

It’s just Python

Hopefully a side-by-side comparison of the Yellow Paper and the equivalent code from EELS can show why EELS is a valuable complement to it:

def less_than(evm: Evm) -> None:
    # STACK
    left = pop(evm.stack)
    right = pop(evm.stack)

    # GAS
    charge_gas(evm, GAS_VERY_LOW)

    # OPERATION
    result = U256(left < right)

    push(evm.stack, result)

    # PROGRAM COUNTER
    evm.pc += 1

While Figure 2 might be digestible to academics, Figure 3 is indisputably more natural to programmers.

Here’s a video walk-through of adding a simple EVM instruction if that’s your kind of thing.

Writing Tests

It bears repeating: EELS is just regular Python. It can be tested like any other Python library! In addition to the entire ethereum/tests suite, we also have a selection of pytest tests.

With a little help from execution-spec-tests, any tests written for EELS can also be applied to production clients!²

Showing Differences

Having snapshots at each fork is great for a smart contract developer popping in to see the specifics of how an EVM instruction works, but isn’t very helpful for client developers themselves. For them, EELS can display the differences between forks:

An Example EIP

EIP-6780 is the first EIP to get an EELS implementation provided by the author, Guillaume Ballet! Let’s take a look.

First, we introduce a created_contracts variable to the EVM with transaction-level scope:

 @dataclass
 class Environment:
     caller: Address
     block_hashes: List[Hash32]
     origin: Address
     coinbase: Address
     number: Uint
     base_fee_per_gas: Uint
     gas_limit: Uint
     gas_price: Uint
     time: U256
     prev_randao: Bytes32
     state: State
     chain_id: U64
+    created_contracts: Set[Address]

Second, we note which contracts were created in each transaction:

+    evm.env.created_contracts.add(contract_address)

Finally, we modify selfdestruct so it only works for contracts noted in created_contracts:

-    # register account for deletion
-    evm.accounts_to_delete.add(originator)
-
+    # Only continue if the contract has been created in the same tx
+    if originator in evm.env.created_contracts:
+
+        # register account for deletion
+        evm.accounts_to_delete.add(originator)
+

Future

We want EELS to become the default way to specify Core EIPs, the first place EIP authors go to prototype their proposals, and the best possible reference for how Ethereum works.

If you’re interested in contributing or prototyping your EIP, join us on the #specifications channel or grab an issue from our repository.

]]> https://earlybirdsinvest.com/ethereum-execution-layer-specification/feed/ 0 26610