The Standardized Interface for Tokenized Vaults

[ercan]

Improvement Idea: The Standardized Interface for Tokenized Vaults

TL;DR: A modular, composable vault interface standard for Sui that unifies vault patterns, reduces code duplication, streamlines developer onboarding, and strengthens auditability.

Problems:

1. Lack of Composability Between Protocols

The absence of composable interfaces across protocols indicates a breakdown in architectural standardization and shared design practices. This limits modular integration and strategic reuse, increasing integration costs and reducing innovation velocity. Addressing this requires unified interface frameworks that facilitate cross-protocol interoperability through common interaction patterns and extensible logic boundaries.

---

2. Not Enough Generic Solutions

A lack of generic, reusable components signals insufficient emphasis on design abstraction and architectural generalization. This leads to ecosystem fragmentation and slows scaling. Governance should promote the development of platform-agnostic standards and incentivize architectural patterns that support multi-context deployment.

---

3. Multiple Duplication of Logic

Duplicated Move modules bloat costs and risks by demanding separate gas profiling and security audits. Consolidating your core logic into a single, versioned Move package and injecting vault strategies via generic type parameters or capability-based hooks would eliminate code duplication. This design promotes Separation of Concerns by isolating core protocol logic from vault-specific behavior, enabling independent reasoning, testing, and auditing. Combined with a Component Repository pattern for shared modules and CI-driven compatibility checks, this approach enables instant update propagation, improves gas efficiency, and shrinks the on-chain attack surface.

---

4. Complexity for Developer Onboarding

Onboarding complexity often stems from unpredictable architecture, undocumented interfaces, and insufficient tooling. Governance should drive standard developer experience practices, enforce consistent interface design, and encourage the use of simplified abstraction layers. This reduces cognitive overhead and accelerates integration and collaboration across new contributors.

Description:

Unified vault standard for protocols ( Yield Strategies, RWA, Lending - Borrowing, etc. )

100% DeFi-compatible shared vault coins.

This proposal aims to establish a standardized and composable vault interface that enhances cross-protocol interoperability, streamlines developer integration, strengthens auditability and control assurance, and reduces redundant implementations — all in alignment with governance principles like process efficiency, reusability, and secure design integrity.

Promotes interoperability and solution reuse

(Manage Solutions Identification and Build)

The SIP vault interface adopts a modular architecture that mirrors principles seen in well-known software abstraction techniques, such as those used to adapt disparate implementations into a shared interface. This design facilitates interoperability and solution reuse, allowing vault logic to be extended and composed across multiple DeFi protocols on Sui without requiring system-specific modifications.

Streamlines developer engagement and contribution

(Manage Human Resources)

By encapsulating complexity within a predictable and narrowly scoped interface — in line with widely used software abstraction strategies — the SIP model lowers the entry barrier for development teams. This structure enhances developer efficiency and coordination, enabling faster onboarding, reduced context switching, and increased focus on innovation rather than infrastructure alignment.

Strengthens auditability and compliance assurance

(Monitor, Evaluate, and Assess Performance and Conformance)

The clearly defined interface boundaries and deterministic behavior of SIP-based vaults support robust auditing and verification practices. Leveraging design patterns that prioritize interface minimalism and explicit contract semantics, this architecture establishes a verifiable baseline for compliance instrumentation, formal verification pipelines, and systematic risk assessment across heterogeneous deployments.

General Idea

The adoption of a unified vault interface will unlock a wide range of DeFi use cases across the Sui ecosystem. Protocols will be able to design modular yield aggregators, offer permissionless structured products, and build automated financial strategies — all through a predictable, composable vault abstraction. This standard enables advanced mechanisms such as meta-vaults, automated rebalancing, AI-managed agent vaults, and collateralized lending markets backed by vault shares. It also paves the way for a shared liquidity layer across protocols, where standardized vault tokens can act as interoperable financial primitives. By establishing this foundation, the Sui ecosystem will be positioned to scale complex yield mechanisms while maintaining composability, gas efficiency, and developer clarity.

[ercan]

Creating Vaults

Vault Metadata Specification

Before creating any Vault, SIP-65 requires you to define a Vault Metadata object. This immutable record declares all of the vault’s configuration fields up front:

• name – human-readable identifier
• description – detailed purpose of the vault
• icon_url – a link in the token metadata that points to the token’s logo image
• input_coin_type – Coin type of the deposited coin
• output_coin_type – Coin type of the minted coin
• version – vault version (For upgradability)

By registering your Vault Metadata first, you guarantee that every vault created thereafter adheres to the same on-chain spec.

---

Objects Created on Vault Instantiation

When you call CreateVault, the protocol spins up three distinct on-chain objects:

Vault (shared object)

• Holds the reserve balances for input and output coins.

Vault Metadata (immutable object)

• Cannot be altered once published, ensuring consistent behavior.

OwnerCap (owned object)

• Issued to the vault creator only.

[ercan]

User Flow

The plot above illustrates how the exchange rate parameter directly controls the number of output coins minted per unit of input deposited. On the x-axis, you see the quantity of InputCoin put into the vault; on the y-axis, the corresponding amount of OutputCoin minted. Each straight line represents a different fixed rate:

• Purple (Rate = 2.0): For every 1 InputCoin you deposit, you receive 2 OutputCoin
• Blue (Rate = 1.0): the “ideal” 1:1 peg—1 OutputCoin per 1 InputCoin
• Green (Rate = 0.5): a conservative rate—0.5 OutputCoin per 1 InputCoin

Because all lines start at the origin, zero deposit always yields zero minting; the steeper the line, the more output you get per input. This linear visualization makes it easy to compare different rate settings and see at a glance how supply imbalances or rate adjustments would shift your output.

[ercan]

Mint

1. Based on the rate, consume the Input Coin and add it to the vault reserve.
2. Increase the supply, based on the rate, and get a balance.
3. Wrap the balance to the Output Coin and return it.

---

Redeem

1. Consume the Output Coin object.
2. Deconstruct it and delete it (delete the ID).
3. Based on the rate, get some balance from the vault reserve.
4. Wrap that balance to the Input Coin and return it

[ercan]

Owner Flow

• deposit (amount: InputCoin): The vault owner deposits an amount of InputCoin into the vault’s reserve.
• withdraw (amount: InputCoin): The vault owner claims an amount of InputCoin from the reserve.

Note: Throughout all steps, the owner never mints or burns any OutputCoin—they only spend or retrieve collateral from the vault’s reserve.

Risk Analysis

(Separation of Concerns)

To ensure future upgradeability and maintain a minimal attack surface, this SIP cleanly separates core logic into modular components—rate computation, reserve management, mint/burn controls, and access permissions each live in their own methods. This design aligns with the Sui Improvement Proposal infrastructure, preserving backward compatibility and enabling seamless, targeted upgrades.

[zark]

I think this is a very good and well-thought proposal. The design feels clean, modular, and elegant, and I believe it could be a major step forward for Sui DeFi.

One suggestion I have is regarding the exchange rate: rather than being arbitrarily set by the owner, it could be dynamically computed based on the vault’s InputCoin balance and the outstanding OutputCoin supply. This would help ensure fair minting and redemption. In addition, since the OutputCoin essentially represents a share of the vault, its token design and metadata could also be addressed in the SIP to provide a more complete and standardized framework.

Overall, this is an impressive and promising design, and I fully support moving it forward.

[deadmanwalking]

This is an excellent and much-needed proposal with clear benefits for DeFi on Sui. Tokenized vaults are arguably the primitive that finally unlocked true composability in other ecosystems that had been striving to achieve it for years, and they clearly have a place here as well.

A few comments on the implementation:

• I agree with the earlier feedback from @zark that the exchange rate should not default to an arbitrary value set by the owner. Instead, it should be derived dynamically, for example via totalInputCoin / totalOutputCoin, to ensure both user protection and predictability in operations.

• This also safeguards fair reward distribution. If the rate can be arbitrarily changed at certain checkpoints, users who have staked for different durations—and therefore taken on different liquidity/smart contract/duration risks—could end up receiving the same rewards upon redemption. Ideally, rewards should remain proportional to both the amount staked (as is already the case) and the duration staked.

Another point for consideration, after reviewing the implementation, is the level of control the owner has over the vault’s reserves. In the current design, the owner has full control and could, in theory, remove all liquidity. This creates a single point of failure (the OwnerCap) and imposes additional trust assumptions on vault users. One possible mitigation would be to require the owner, instead of directly withdrawing InputCoins from the vault, to create a WithdrawalRequest “hot potato” object that can only be consumed by a set of whitelisted strategies. This would make fund flows transparent and allow users to verify exactly how their funds are being utilized.

Overall, I want to echo previous comments: I fully support this initiative and am very excited to see how it develops. Great work!

[ercan]

Thank you for the precious feedbacks! That is really helping us the perfect the SIP

The main issue is that in many yield strategies, if the only way to increase the rate is by pulling liquidity out of strategies just to deposit it back into the vault, it becomes inefficient and operationally clunky. This creates unnecessary transaction overhead and potentially interrupts compounding.

A possible improvement is tracking an additional parameter — let’s call it usedReserve — alongside the standard totalReserve. When strategies generate yield, they could “credit” this yield into usedReserve without physically withdrawing the liquidity from active positions. The exchange rate could then be computed from totalReserve + usedReserve (or a weighted variation), so rate increases happen seamlessly while strategies remain fully deployed.

On the Hot Potato withdrawal pattern: I see the security benefits, especially for user trust and transparency. Routing withdrawals through whitelisted strategies means the community can verify exactly how funds are being deployed. The trade-off is potential loss of direct plug-and-play composability with other DeFi protocols, so we’d need to assess whether to make this pattern optional or mandatory per vault type.