Introducing Definica: Proposed Addition of EthPooledStakingVault to StakeWise’s VaultsRegistry

Ideas
1

Hello StakeWise community,

We are the team behind Definica, an independently developed Ethereum-native protocol being built to connect pooled ETH staking, transparent position accounting, planned osETH liquidity, and future borrowing markets for approved ETH-correlated collateral.

We are opening this discussion to introduce our architecture, explain why we chose StakeWise, and gather feedback before preparing a formal proposal to add our EthPooledStakingVault to the StakeWise VaultsRegistry.

Five days ago, on 16 September 2026, we emailed the StakeWise team with our technical overview, contract references, review findings, and proposed onboarding plan. We have not yet received a response. We subsequently followed up with the StakeWise team via Telegram but have not yet received a response through that channel either. As outlined in that email, we are now bringing the idea to the community for open discussion. We welcome input from the team, contributors, operators, and SWISE holders throughout this process.

Definica is being developed through three stages, with each stage establishing the technical and risk foundations required by the next:

Stage 1 - Pooled ETH staking through DefinicaCore. DefinicaCore is our user-facing staking and accounting layer. It routes deposits into a dedicated StakeWise-derived Vault, holds the resulting Vault shares, and records each participant’s proportional position. It coordinates withdrawal requests, claims, and optional share lockups. Users can participate without individually funding a 32 ETH validator or operating validator infrastructure. Their economic exposure follows Vault accounting, including staking rewards, MEV, fees, penalties, and exits.

Stage 2 - The planned Main Liquidity Module. We intend to develop an osETH-based liquidity layer using an activated Aave-compatible market route. Eligible supplied osETH positions would be represented as aEthosETH, with defined accounting, lock, withdrawal, capacity, and incentive rules. This represents a supplied position, not an additional ETH deposit or a duplication of staking returns. The exact route and dependencies require separate implementation and review.

Stage 3 - Future ETH-correlated borrowing markets. We plan isolated markets in which approved ETH-correlated positions can serve as collateral for borrowing a supported asset. osETH is the planned initial collateral foundation. Each market would require its own oracle, LTV and liquidation parameters, interest model, caps, and operational controls before activation. Potential uses of aEthosETH would be assessed separately for each market. Borrowing introduces debt and liquidation risk and is not currently offered by Definica.

Our present request concerns Stage 1 and ETH pooled staking. Neither the reviewed EthPooledStakingVault implementation nor DefinicaCore contains an osETH minting path. Deposits into this Vault create internal Vault shares, not osETH. Later osETH functionality would use a separately specified eligible route; this Vault’s registration would not itself enable or approve those later modules.

EthPooledStakingVault is closely derived from StakeWise’s EthFoxVault, the implementation associated with MetaMask Pooled Staking, and incorporates selected functionality from official StakeWise contracts. We selected that baseline because its ETH-only pooled staking model fits our initial product. The objective is to provide a similarly focused staking foundation through DefinicaCore, with transparent accounting and clearly defined deposit and withdrawal mechanics. Definica’s modifications focus on integrating these existing mechanisms into the inherited architecture, modernizing the Vault’s capabilities while retaining its underlying pooled ETH staking and accounting framework.

Our comparison covers 46 Solidity files, including interfaces and dependencies. After normalizing naming, comments, and import paths, 40 files are unchanged. The original deposit and exit implementations, validator registration, MEV handling, blocklist administration, and Vault upgrade authorization are retained. The principal additions are:

  • donateAssets() and its pending-donation accounting, allowing ETH contributions without issuing additional shares.

  • donateShares(), allowing holders to burn their own shares while leaving the corresponding assets in the Vault.

  • Donation recognition during updateState, together with the related storage and events.

  • getExitQueueData() for consolidated queue reporting, and an admin fee setter subject to an update interval and rate-increase limits.

The donation functions and associated harvest-accounting logic originate in official StakeWise implementations: VaultEthStaking and VaultState. We adapted their placement and interfaces to the EthFoxVault baseline. These are targeted backports of StakeWise functionality, while DefinicaCore and the integration-specific adaptations remain our responsibility. Compatibility with current StakeWise operator and oracle infrastructure must be assessed for the resulting implementation.

The Vault uses a standard OpenZeppelin ERC1967Proxy. It is a fresh deployment with its own identity and storage layout, rather than an upgrade of an existing EthFoxVault. Core uses a separate compatible proxy and maintains its own application-level accounting.

We chose StakeWise for its modular staking architecture and community governance. Dedicated Vault accounting provides a clear boundary for deposits, validator performance, fees, and exits. Its permissionless standard Vault deployment model and operator flexibility support independent staking configurations; our custom deployment follows the separate admission process discussed here. Published contracts and review materials make the underlying mechanics inspectable. Together, these characteristics fit our goal of building ETH infrastructure whose behavior users and reviewers can understand.

StakeWise’s native Ethereum osETH infrastructure also fits our longer-term liquidity plans, subject to the separate eligibility, collateralization, and integration requirements of those future stages. Our decision therefore reflects both the suitability of the EthFoxVault baseline for Stage 1 and the broader ecosystem in which later functionality could develop.

For Definica, StakeWise offers an established staking foundation, operational expertise, and an ecosystem in which we can build a dedicated user experience without designing an entirely separate validator-accounting system.

For StakeWise, Definica could bring additional ETH stake, new users, another application built around its Vault infrastructure, and practical integration feedback. Later development may also expand osETH utility. These are opportunities we intend to work toward, rather than guaranteed TVL or adoption commitments.

There is a relevant governance precedent in SWIP-17, which sought approval to register a custom Vault so that the Oracle Network could support its validator-related operations. We recognize that our deployment requires its own technical review and governance decision.

The proposed registry action would concern the Vault proxy, through VaultsRegistry.addVault(vaultProxy). DefinicaCore is the application interacting with that Vault and is not the address proposed for registration. The contract references for this discussion are:

Contract Ethereum mainnet address
EthPooledStakingVault proxy 0xe0Ce41b9384a8A89355704bb6122c4ae3fEf538c
DefinicaCore proxy 0xD1Dda794da5438f646Fc7EA8a8DA892BF9359193
StakeWise VaultsRegistry 0x3a0008a588772446f6e656133C2D5029CC4FC20E
EthFoxVault - MetaMask: Pooled Staking Vault proxy (reference) 0x4FEF9D741011476750A243aC70b9789a63dd47Df

Our proposed next steps are:

  1. Keep this initial discussion open for approximately ten days, extending it if technical questions remain unresolved.

  2. Gather feedback and provide the complete source comparison, compiler settings, configuration details, role assignments, test results, and any required remediation for review.

  3. Confirm a workable operator and oracle integration and, if there is community support, prepare a formal SWIP specifying the exact registry action and its technical conditions.

  4. Follow StakeWise’s published specification, forum-poll, Snapshot, and execution requirements.

  5. If approved, coordinate the authorized registry action and complete operational validation before enabling public staking through Definica.

We welcome feedback on the proposed Vault architecture, Core accounting, operator compatibility, security review requirements, and the information the community would need before considering a formal proposal.

Our aim is to build a useful, transparent integration that earns the confidence of StakeWise contributors, operators, and users through review and demonstrated operation. Thank you for considering the idea and helping us determine the appropriate next steps.

The Definica Team

Definica’s website and social media channels:

1 Like
2

Hi Definica team,

Welcome to the StakeWise DAO forum and thank you for the extensive write-up and integration work seemingly conducted so far!

We always encourage communication through governance channels, and our silence has arguably been warranted - the team gets a lot of phishing emails, messages, and generally scamming attempts, so having a public discourse is one of the best ways to discuss your proposal.

Since this is a venue for community discussion, I will only share my personal perspective on your proposal, which is partially backed by the team’s assessment of the technical details.

The Vault system is, as you mention, flexible and modular, and the capabilities of Vaults out of the box far exceed all the available solutions on the market. From this perspective, a wholly new implementation, no matter how many features it inherits from EthFoxVault or another, must be justified both financially and from a security perspective.

You can see that EthFoxVault is an outlier that doesn’t share the feature composition with other Vaults. However, in its case, an auxilary imlementation made sense because a) StakeWise DAO stood to greatly benefit from the implied volume of business that a native MetaMask wallet integration would bring, and b) was thoroughly audited by Consensys Diligence, alongside the whole protocol, including the impact of a new, standalone Vault implementation on the rest of the system.

With this in mind, I want to say that Definica’s proposal is in its current form a rather dangerous and potentially ineffective SWIP for the StakeWise DAO to pursue, for 2 reasons:

  1. The size of the business opportunity for StakeWise is unclear. Staking is a distribution business, and an upstart like Definica should possess a clear plan for user acquisition, which unfortunately hasn’t been shared. What was shared is a rather vague roadmap that includes the addition of donation functions, the value of which for the end user (and hence the implementation within the StakeWise ecosystem) is unclear, an establishment of a seemingly important feature where users can supply osETH on Aave through Definica, which is trivial, and the creation of credit markets for assets correlated with osETH, seemingly also built around Aave, which again is obfuscation of the true service provider. In light of this, in order to not be misunderstood, I encourage you to share more details around the reason for including donation functions, size of the opportunity for StakeWise, Definica’s roadmap details, and go-to-market info. With this at hand, I believe our community can make a more informed opinion about the merits of your proposal.

  2. Lack of security analysis around the proposed implementation. This is a must, as StakeWise DAO strongly adheres to the strictest of security practices and wouldn’t even be ready to have a conversation about any smart contract changes before understanding their impact deeply and at every level of the system. It is alarming that your proposal doesn’t contain one, and frankly could be considered a red flag, especially when paired with a sponsored article, lack of attached information about the core team members, and a very limited online footprint.

Hence, my personal stance is currently rather negative, as the proposal, despite its technical details around the addition of new functions, is very surface-level, and could be justifiably perceived as a potential exploit vector if successful.

So please, if your proposal is genuine and you are serious about the outlined products, I encourage you to offer the requested information for our analysis and discussion. Thank you.

1 Like
3

Hello, and thank you for your detailed feedback.

Our original Ideas post was intended to introduce Definica and open a discussion before a formal SWIP. We brought it to the forum after our earlier email outreach had not received a response. We understand your concerns about unsolicited approaches and agree that the proposal should be assessed through a public governance process.

You are right that our introduction needed a clearer commercial case and supporting security material. Definica is at an early stage, financed by its team members using secured private capital. We have no official distribution partnerships or committed TVL to present at this point.

Our immediate objective is to launch pooled ETH staking through DefinicaCore and seek registration of EthPooledStakingVault, subject to the required review and governance approval. Core manages users’ proportional positions, withdrawals, claims, and optional share lockups. Stage 1 is the foundation on which we intend to build the later liquidity and borrowing modules.

We selected StakeWise because its Vault model fits our requirements for independent Vault management, position accounting, and control over adopting approved upgrades. We considered Lido’s stVault model, but its architecture and operational framework did not meet the requirements we had defined for Definica. StakeWise better aligned with the way we intend to operate the initial staking product and develop subsequent integrations.

EthFoxVault provided an ETH-only baseline suited to that initial scope. Our reference to MetaMask concerned the implementation model; Definica’s distribution potential and security must be assessed on their own evidence. We are also open to reviewing whether a supported standard Vault could meet our requirements with less integration and maintenance work.

Our acquisition plan is deliberately incremental:

  • Before official launch: publish a working product demonstration and documentation, build an early-access list, and test the full deposit-to-withdrawal journey with prospective users. The interface and onboarding material would clearly identify StakeWise and the applicable fees, withdrawal conditions, and risks.
  • At launch: begin with limited onboarding and direct user support. Measure conversion, withdrawal completion, and early retention, then use those results to improve the product and establish acquisition budgets.
  • As the project develops: pursue integrations with wallets, portfolio applications, DeFi aggregators, and other platforms serving ETH holders. We would offer documented integration paths, product demonstrations, and measurable pilots, starting with listings, referral routes, or deep links where appropriate. Direct outreach to platform teams and joint onboarding campaigns would support this effort.

Direct marketing would include opt-in email campaigns, early-access follow-ups, product walkthroughs, community discussions, search-oriented educational content, and limited paid campaigns. Promotional collaborations would be disclosed. Spending would increase only where funded-user conversion and retention support it.

We would track acquisition cost per funded user, net ETH inflows, and 30/60/90-day retention, including retention after incentives and lockups expire. For StakeWise, the intended contribution is additional retained stake and distribution through Definica. We would distinguish new capital entering StakeWise from transfers between existing Vaults and present adoption scenarios alongside the cost of supporting our integration.

The purpose of including donateAssets() and donateShares() is to support a defined treasury contribution policy. These are existing StakeWise functions incorporated into our EthFoxVault-derived implementation. Our proposed use is to direct a portion of realised Definica revenue, eligible incentives, and budgeted treasury capital toward the value of remaining Vault shares.

Definica’s multisig would hold Core’s donator() role. It could contribute ETH through donateAllAssets(), which forwards it to the Vault’s donateAssets(), or call donateShares() directly to burn shares owned by the multisig.

For the economic effect, let A represent accounted Vault assets, S > 0 total shares, and P = A / S the value per share. Excluding fees, unrelated rewards or losses, rounding, and exit-queue changes:

  • ETH contribution: once a donation of D > 0 is recognised, P_after = (A + D) / S. The increase per share is D / S.
  • Treasury share burn: burning B shares gives P_after = A / (S - B). For A > 0 and 0 < B < S, the relative increase is B / (S - B).

In our implementation, ETH contributions enter accounting on a subsequent successful new harvest and are subject to the resulting net asset and fee calculation. The share-burn route reduces supply while retaining the backing assets. The treasury would select the route according to the assets it holds and the intended contribution.

Shares used for burns would come from the multisig’s own Vault deposits or fee allocations. Our earlier “buyback-and-burn” wording therefore refers to treasury-funded acquisition through deposits followed by donation; it does not imply a secondary market for these internal shares. Core’s user balances would not fund those burns.

The benefit applies across the remaining Vault-share base, including both locked and available Core positions. A donation does not preferentially reward longer locks. Any incentive specifically for locking a position would be accounted for separately. Contributions would remain budget-dependent, and returning Vault fees would be reported as a rebate rather than additional validator yield.

On security, DefinicaCore and EthPooledStakingVault have undergone two private audits. We can provide the reports through an agreed formal channel, with the audited revisions, scope, findings, and remediation status. We recognise that the relevant question is whether that coverage adequately addresses the implementation and integration being proposed to StakeWise.

For a formal submission, we would provide the source comparison against EthFoxVault, reproducible builds, deployment configuration, privileged roles, upgrade controls, and integration tests. Any gaps in coverage, including effects on shared StakeWise infrastructure, would need to be addressed before registration. The origin of the reused functions does not remove that obligation.

Regarding the roadmap, Stage 1 remains ETH-only pooled staking. The current EthPooledStakingVault does not mint osETH. The later stages would introduce separate contracts and require their own security assessment.

Stage 2 would manage osETH supply positions and liquidity commitments. Users could supply osETH to an eligible Aave market and lock the resulting aEthosETH position in Definica’s future module, or deposit a compatible aEthosETH position directly. We also plan a separate osETH-enabled Vault, deployed through an appropriate StakeWise Vault Factory, through which users could stake ETH and mint osETH before entering the same flow.

For users opting into the financed strategy, the module would use the supplied osETH position represented by aEthosETH as collateral to borrow an asset from Aave. WETH is one intended option; other assets could be used where permitted by the selected deployment and active eMode category. Each route would depend on compatible collateral and borrowing permissions, available liquidity, caps, and Definica’s own market configuration.

Stage 3 would make that borrowed asset available as lending liquidity. Borrowers would obtain it against approved ETH or ETH-correlated collateral and pay interest. Users could also supply their own ETH directly to Stage 3, without the preceding osETH and Aave financing steps.

The connection between the stages is therefore practical: Stage 2 manages the committed position and its financing; Stage 3 uses the resulting liquidity in its lending markets. Definica would coordinate custody, debt attribution, interest allocation, and exits. Aave would be explicitly identified as the provider of the underlying supply position and funding loan, and any external infrastructure used in Stage 3 would likewise be disclosed.

We also intend to offer separate incentives for locking eligible aEthosETH positions. These would compensate participants for committing liquidity under defined terms, with eligibility and allocation taking account of the committed amount and lock duration. The programme’s budget, funding source, and calculation method would be published before activation. Funding would come from an allocated treasury budget and/or realised protocol revenue. Those incentives would be reported separately from lending interest and Vault-wide donations; the lock itself does not generate income.

Our proposed fee model is a 25% protocol share of Stage 3 lending interest allocated to each participant. If I_u is that participant’s attributable lending interest:

Definica revenue = 0.25 × I_u

User interest allocation = 0.75 × I_u

Allocation would follow the participant’s attributable lending balance and interest accrual over time. For the financed route, the Aave borrowing cost and other applicable strategy costs must then be deducted. Accordingly, the Stage 3 component would be:

User net lending result = 0.75 × I_u − funding costs − other applicable costs

Amounts would be calculated in consistent units for the relevant asset. Separately allocated lock incentives would be added to the participant’s reporting, alongside the applicable staking and Aave supply components, without counting the underlying stake and its token representations multiple times. The financed strategy can produce a negative net result if its costs exceed its income.

Definica’s retained share would support development, operations, and disclosed incentive programmes, including potential treasury contributions to the Stage 1 Vault. Additional revenue could include published operation fees and a defined protocol share of liquidation fees in our own markets. These would be distinct from borrower debt repayment and liquidator compensation.

For exits, the module would apply published liquidity thresholds and withdrawal conditions. Where sufficient borrowed assets are available to the participant’s position, after reserving amounts owed to others, the intended sequence is:

  1. Repay the attributable Aave principal and accrued interest in the asset owed.
  2. Withdraw the corresponding osETH from Aave by redeeming the aEthosETH position, subject to available reserve liquidity and remaining collateral requirements.
  3. Where the user originally minted osETH through our future factory-deployed Vault, burn the required osETH to settle that minting liability, including accrued fees. Any shortfall would need to be covered before full closure.
  4. Withdraw the released Vault shares through its normal exit process and settle the user’s remaining liquidity, interest, and earned incentives.

A user entering with existing osETH and no associated minting position would skip steps 3 and 4 and receive osETH, with the option of using the available ETH redemption route. Direct ETH suppliers would follow Stage 3’s withdrawal process. Lock expiry would end the commitment period, while actual settlement would still depend on available liquidity and repayment of the relevant obligations.

This is the intended service beyond simply providing an Aave deposit interface: coordinating committed staking-related positions, financing, lending liquidity, incentives, and an accountable unwind. Each market would have published collateral and borrow assets, oracles, LTV and liquidation thresholds, interest parameters, caps, and exit rules.

Regarding the team, we had planned to publish profiles alongside the final website and dApp. We are willing to publish team information or provide verifiable identities and backgrounds directly to you before a formal SWIP, in line with the DAO’s due-diligence requirements.

The current website is informational. Our target remains to release the new website and dApp in a little over 30 days, with public staking subject to security review, operational readiness, and the necessary approvals. The sponsored article was introductory marketing; we understand that your assessment requires independently reviewable technical and commercial evidence.

Our proposed next step is to agree with you on the review requirements.

The Definica Team

4

Thank you for the clarification @definica. Before asking the DAO to commit further to your proposed implementation, please provide verifiable team identities and relevant experience, the two audit reports with their scope, audited code revisions and remediation status, and a concrete commercial case explaining why a custom Vault is necessary and what distribution or committed capital Definica brings. Further descriptions of intended processes cannot substitute for this evidence. Until it is available and the technical concerns are resolved, you should expect the team to vote against proposals seeking approval to proceed with this implementation. Community members remain free to assess the proposal and vote independently.

5

Dear StakeWise team and community,

Please accept our apologies for the delay in responding. We have been reviewing your full feedback internally and discussing the technical, security and organisational work required to move Definica forward responsibly.

Your previous responses made clear that our initial introduction left important questions unanswered. We recognise that the information presented so far has not established the level of confidence we want to build with the StakeWise team and community.

Our immediate priority is to clarify the proposal and its requirements before taking the next formal step. We want to establish a shared understanding of what Definica intends to deliver, why the proposed implementation is needed, how it would interact with StakeWise, and what evidence should support its assessment. This includes distinguishing the current staking implementation from the planned liquidity and borrowing modules.

We have therefore decided to prepare a comprehensive due-diligence submission and seek a structured review with StakeWise before progressing towards a formal proposal for the inclusion of EthPooledStakingVault in VaultsRegistry. Our next steps are:

  1. Technical and commercial clarification. Prepare a consolidated package covering DefinicaCore and EthPooledStakingVault, their differences from upstream implementations, integration assumptions, administrative and upgrade permissions, treasury arrangements, user-acquisition strategy and the proposed benefit to StakeWise. We would welcome your guidance on the appropriate review process. Agreeing on the scope and outstanding questions first will help us provide the material needed for a meaningful assessment.

  2. Sharing existing audits and arranging additional reviews. We would be pleased to share the reports from the two private audits already carried out through an appropriate review channel. Alongside those reports, we will provide the relevant scope, reviewed code versions and remediation information. We also intend to commission additional independent audits to strengthen the technical evidence available and build greater confidence among the StakeWise team and DAO community. We would welcome input on any integration-specific areas that should receive particular attention. Our aim is to make the findings and their resolution assessable, rather than relying on the number of audits alone.

  3. The complete website and dApp. Publish the full version of our website and release the dApp as the relevant readiness requirements are met. The current website serves primarily as an introduction. The complete release will provide clearer product documentation, contract references, operational information and explanations of user positions and withdrawal conditions. It will also distinguish available functionality from features awaiting activation or further development.

  4. Leadership information and accountability. Publish the identity and relevant professional background of Definica’s CEO, together with further information about project responsibilities. We understand the importance of giving the community a clear view of who is responsible for development, administration and delivery, and we are willing to provide information required for due diligence.

  5. A detailed implementation roadmap. Expand each of our three stages into specific workstreams, deliverables, dependencies and release conditions. This will explain how Stage 1 pooled staking connects to the planned Stage 2 liquidity module and Stage 3 borrowing markets. Each segment will identify the development, review and operational work involved, making the boundaries between implemented functionality and future plans explicit.

Our objective is to earn the full confidence of the StakeWise team and community through transparency, independent assessment and consistent delivery. In this sector, trust depends on being able to verify the information presented, understand who is accountable and follow how outstanding questions are resolved.

For that reason, we want to use this stage of the discussion to clarify expectations on both sides. Before submitting a formal proposal, we would like to understand which aspects require further justification, what documentation or analysis is expected, and whether any fundamental technical or commercial concerns remain.

We therefore publicly invite the StakeWise team to provide its official assessment of this updated approach, in response to the concerns raised in your previous posts. Would these proposed steps provide an appropriate basis for further evaluation, and what additional information would you expect us to present to the DAO community?

A public response would help us prepare a focused submission and allow the community to follow the discussion with a clear understanding of the remaining work. We recognise that the team’s assessment and any subsequent DAO governance decision are separate.

The Definica team