Smart Contract

Overview

The Vorn Protocol introduces a novel smart contract system built on the combination of two advanced Ethereum token standards: ERC-4626 (Tokenized Vaults) and ERC-1410 (Partially Fungible Tokens). This dual-standard approach forms the foundation of Vorn's investment abstraction layer, enabling capital allocation across multiple strategies while preserving a unified accounting interface.

At the execution layer, ERC-4626 serves as the standardized mechanism for interacting with external yield-generating protocols—including ETH staking and restaking infrastructures. Each vault adheres to the ERC-4626 specification, allowing Vorn to seamlessly integrate with third-party protocols while ensuring consistent accounting for deposits, shares, and yield accrual.

To resolve the fragmentation introduced by managing multiple vault tokens, Vorn wraps these vaults under a single ERC-20-compatible interface using ERC-1410. ERC-1410 extends the standard token model with partitions—logical subdivisions of a user’s balance that represent ownership in distinct vaults. Each partition corresponds one-to-one with an underlying ERC-4626 vault, allowing users to hold strategy-specific exposure without minting multiple tokens or managing separate positions.

This results in a single token, whyETH, that represents the user’s entire portfolio. Behind the scenes, the token’s balance is segmented into partitions, each governed by vault-specific logic and tracking. These partitions are fully programmable, enabling granular access control, vault-specific permissions, and real-time rebalancing.

All partition logic is handled at the contract level, abstracting complexity from the user while retaining on-chain composability. As a result, vault creation, user deposits, and portfolio reallocation are all managed through modular, upgradeable contracts, built to scale as new staking, restaking, or yield strategies are onboarded.

This smart contract architecture allows Vorn to present a unified, liquid interface for users—while maintaining a high-resolution, protocol-level representation of capital allocation beneath the surface.

whyETH Balance and Exchange Rate

The Partially Fungible Token Standard defines explicitly this mechanism regarding balance and token supply:

• balanceOf:

  • aggregates a token holder's balances across all partitions

  • MUST count the sum of all partition balances assigned to a token holder

• totalSupply:

  • returns the total amount of tokens issued across all token holders and partitions

  • MUST count all tokens tracked by this contract

Constant balance and dynamic exchange rate

The solution proposed is to respect the 1410 standard definition. balanceOf function on whyETH token will be calculated as the number of shares that the user holds on each vault or partition. There will be functions like getUnderlyingValue, which gives the global ETH-denominated value that is theoretically managed by all the partitions and can also be calculated for each address. However, this is a complementary feature and not the core of the token (like balance). There is no big disadvantage in having low precision or some grade of obsolescence in the computed value, or at least this would have a lower impact. This means that we can consistently work on a robust protocol architecture that decouples the evaluation from operation by design, allowing it to be scalable and extendable in the future. Also, it will be reasonably more feasible to build secondary market incentives and propitiate integrations of whyETH on other protocols. Finally, the totalSupply identity will be kept valid all the time.

One argument that can be made against this approach is the question of what exactly the balance represents here. It is the accumulation of shares of different investments, so it is actually the accumulation of different units of account. It is like computing an additional 1 BTC + 2 ETH, so you are getting 3 of what. This is the impact of the Partially Fungible Token concept, and maybe it’s hard to understand at first sight. But finally, it doesn’t affect what we can do with the token. For example, two deposits of the same amount of ETH split into different vault sets will produce different balances but represent the same underlying value. The answer is that it’s pretty much the standard situation on any vault or protocol working under ERC4626, where even consecutive deposits of the same amount also give different amounts of shares as a result. So, this is not necessarily a problem.

Is it worth tokenizing ERC1410 partitions?

By representing partitions as vaults, we are tokenizing shares. There could be a gas cost increment because of this tokenization, depending on the implementation alternative that is used as a benchmark. However, architecture benefits from great flexibility. The architecture and the business model potentially get the same benefits. Some internal market dynamics can also be addressed because of this tokenization of shares. For example, withdrawals can be guaranteed by buying back shares, setting an auto-rebalancing mechanism between the vault’s shares tokens (similar to balancer pools), vaults can even implement strategies using other vaults as intermediaries, etc.

Partially Fungible Token Transfers

It is key to understanding how partially fungible token transfers work. There is no single value stored at the smart contract state that says what the current balance of an address is. It’s calculated as the accumulation of a partition’s shares. This means that instead of affecting two balances (sender and receiver) as in a typical fungible token, here we need to execute several transfers of the underlying partitions (vaults) on which the sender address participates. So every whyETH transfer execution actually wraps underlying shares' transfers. The result of a whyETH transfer is actually to change the ownership of some underlying vault’s shares.

But nothing is said, as a restriction, about which shares, or how much of them, should be transferred. This means that the transfer function in the whyETH token contract can implement custom logic. We can also configure the logic by hooking and isolating the transfer strategy in a different contract. This feature could be used to build incentive mechanisms and secondary markets that behave differently, even using the same token.

Some examples would be:

• Proportional transfers: transfer the same proportion of each vault share affected by the sender. This keeps the same sender’s exposure to their vaults but with less amount and underlying value.

• Filter by vault: Vorn would want to stop some vault transfers. Under an emergency pause of one vault because of a hack or because of maintenance due to an underlying protocol upgrade. In this case, the default behavior could be to keep going with whyETH transfers affecting any other vault, and with those that affect the paused vault still be executed but assuming a changing exposure of the sender as a result, or also the user could decide to revert if his portfolio will get affected.

• Filter by the sender: we can implement different logic known addresses, like the contract address of a pool or any external protocol. For example, having different pools on DEX’s trading on top of whyETH. The transfer strategy could be to restrict access to pools just to a set of vaults grouped by risk.

Transfer Strategies

whyETH is an ERC-20-compliant contract at the interface level, but its internal logic diverges significantly from standard ERC-20 implementations. This deviation is similar to what we see in rebasable tokens, where balanceOf is not resolved through a simple mapping lookup. Instead, in whyETH, the balanceOf function returns the aggregated total of shares held by a given address across all supported underlying vaults.

As such, balances are not intrinsically stored within the whyETH contract but are instead calculated dynamically based on the state of the underlying vault contracts. This design allows for partial fungibility and abstraction but introduces a more complex transfer execution model.

When a transfer is executed on whyETH—unless the amount represents 100% of the sender’s balance—there are multiple valid combinations of vault shares that can be used to fulfill the transfer. This means that the same transfer call can follow different logical paths, each affecting a different subset of vault shares.

A core innovation of the Vorn Protocol lies in the transfer resolution algorithm, which determines exactly which subset of shares should be reallocated during a transfer. This algorithm is not user-configurable; it is managed by the Vorn Protocol administrator or governance DAO.

There are two key components that define the Vorn Protocol’s Transfer Policies:

1. The criteria on which the algorithm of a transfer will change and why. Specifying concrete thresholds and metrics to be monitored continuously.

2. The algorithm to be used. This includes the expected results of the affected vault’s shares.

Transfer strategies refer to the fact that different logic can be applied to transfer executions on whyETH. Transfer policies can be understood as the conditions and context under which each different transfer strategy should be used.

whyETH could theoretically expose a transferByVault function, allowing users to specify the exact vault shares to transfer. However, implementing such a function would undermine the very design principles behind a partially fungible vault aggregation mechanism. As a result, this function is deliberately excluded from whyETH. Consequently, anyone holding whyETH implicitly agrees to adhere to the transfer policies established by the Vorn Protocol. Transfer policies should be established to support the Vorn Protocol's growth and long-term stability goals, and holders' rights should never be restricted except in cases of critical security emergencies.

Risk and Yield exposure

When someone makes a deposit, they select the amount of ETH they want to allocate to each vault or staking/restaking/yield boost module. As a result, the depositor receives a certain amount of whyETH balance, but with a specific risk and potential yield exposure based on their portfolio configuration. Another user, even with the exact same whyETH balance, will typically have a different risk and yield exposure. This means that whyETH token holders do not share the risks and yields taken by other users. This is true at the Vorn Protocol level, particularly when considering withdrawal rights. However, this may not be the case at the secondary market level.

Holding whyETH represents certain specific withdrawal rights, which are shared only among holders of the same vault. This is generally not extendable to all whyETH holders, due to differences in the vault exposure combinations preferred by users.

In secondary markets, the situation may differ when we consider “exposure” reflected in whyETH’s traded price under certain edge cases—such as a staking protocol depegging, a hack, or an extremely high yield in a specific vault. Users who are directly involved in those vaults will be affected at the Vorn core protocol level. However, in secondary markets—such as DEX pools that implement a proportional transfer strategy—exposure depends on how many shares of the affected vault are actually held by the pool.

Generally, the traded price is expected to reflect a variation similar to the weighted change in the TVL managed by the Vorn Protocol, at least statistically. This creates arbitrage opportunities, encouraging the sale of whyETH by holders without exposure to a particularly high-yield vault, or putting pressure on holders of vaults impacted by hacks or rug pulls. On the other hand, buyers may step in to establish a floor price when the cost of acquiring whyETH is lower than the cost of depositing directly into Vorn with a uniform vault distribution.

Withdrawals flexibility

Whenever a whyETH token holder wants to withdraw their underlying value (ETH), the typical scenario is that Vorn will burn shares and return the respective amount of ETH to the user. However, there is significant flexibility in how that withdrawal can be fulfilled. We are proposing an architecture that supports a configurable withdrawal strategy.

A configurable withdrawal strategy means that some vaults can cover withdrawal costs differently. Just to mention some potential cases:

• Relying on the underlying protocol’s withdrawal mechanism — this will be the default at the MVP stage.

• Using a reserve-incentivized mechanism via a lending protocol’s stability pool.

• Taking on debt through third-party protocols — for example, using stETH as collateral on a CDP protocol to mint a certain amount of stablecoins, purchase ETH, and cover the withdrawal.

• Drawing debt from other vaults.

Finally — and this is also key — users can withdraw simply by selling their whyETH on a DEX, as long as healthy transfer strategies are in place. The more liquid the secondary market Vorn can build, the less TVL will exit the protocol through direct withdrawals, allowing internal features to better leverage DeFi integrations.

Smart Contract Architecture

Class Diagram

• Vaults Factory: Deploys the vaults and defines a default fee to use when none is specified

• Vaults Registry: Keeps track of deployed vaults and the ability to disable or delete one. This concept could be merged with Vaults Factory

• whyETH: An ERC-1410 contract model (ERC-20 compatible), serving as the main and only unit of account. Users interact with this contract as the primary entry point to the protocol. It provides all protocol functionalities and keeps track of each vault in which the user holds assets.

  Each partition of whyETH corresponds to a specific vault, and this contract holds all the user’s shares. A user’s whyETH balance is represented by the shares obtained upon deposit.

  The valued balance in ETH for a user’s whyETH holdings is calculated as the sum of all shares held by the user, each multiplied by the exchange rate of the respective vault in which assets are deposited.

• Vault: an ERC4626 vault standard (ERC20 compatible). Each vault will interact with an external protocol using a single strategy. It will mint shares to whyETH immediately when assets get deposited. Still, it will hold the assets to reach a certain threshold to deploy them on the external protocol through its adapter. This will shorten the qty of transactions and save a lot of gas. This process will be triggered by the execute Capital Deployment() function.

• Vault Strategy: This contract will hold three important functions

  • executeHarvest(): Calls the adapter to close positions or sell assets in order to fulfill a withdrawal or to realize earnings.

  • updateValuation(): Retrieves the currentValuation from the adapter without initiating communication with the external protocol.

  • executeCapitalDeployment(): Deploys vault assets and takes positions on external protocols as needed.

  This concept could potentially be merged with the Vault contract or the Adapter contract.

• Adapters Factory: Responsible for deploying adapters.

• Adapters Registry: This contract keeps track of deployed adapters and allows users to disable or delete them. It could potentially be merged with Adapters Factory and Vault Strategy, incorporating the ability to define strategies and communicate with external protocols. The contract will maintain an array of valid adapters, which will be iterated over to update the current value of assets deployed in each protocol.

• Adapter: This is the component that directly interacts with external protocols. Unlike the other components, each adapter contains protocol-specific code tailored to the external protocol it integrates with. Adapters will implement base functions with generic names to support common external operations, but the underlying logic will vary per protocol. In some cases, the sender address will be responsible for capital deployment—meaning the adapter itself may hold positions in the external protocol. For this reason, the adapter’s responsibilities could also be merged with the Vault or Vault Strategy contracts.

• Withdrawal Strategy: This component defines how a vault responds when a user initiates a withdrawal or redemption. It is decoupled from other components to allow easy replacement or modification in future iterations. In the initial implementation, it will rely on the external protocol.

• Transfer Strategy: This component defines how whyETH token transfers are handled.

Operation Flows