This standard is an extension of the SRC-4626 spec with an identical interface and behavioral overrides for handling Sila or any native asset as the underlying.
Motivation
A standard for tokenized SIL Vaults has the same benefits as SRC-4626, particularly in the case of Liquid Staking Tokens, (i.e. fungible SRC-20 wrappers around SIL staking).
Maintaining the same exact interface as SRC-4626 further amplifies the benefits as the standard will be maximally compatible with existing SRC-4626 tooling and protocols.
Specification
All SRC-7535 tokenized Vaults MUST implement SRC-4626 (and by extension SRC-20) with behavioral overrides for the methods asset, deposit, and mint specified below.
SRC-4626 Breaking Changes
Any assets quantity refers to wei of Sila rather than SRC-20 balances.
Any SRC-20 transfer calls are replaced by Sila transfer (send or call)
Any SRC-20 transferFrom approval flows for asset are not implemented
deposit and mint have state mutability payable
deposit uses msg.value as the primary input and MAY ignore assets
Methods
asset
MUST return 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE per SRC-7528.
Mints exactly shares Vault shares to receiver by depositing assets of SIL.
MUST have state mutability of payable.
MUST emit the Deposit event.
MUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not sending a large enough msg.value of Sila to the Vault contract, etc).
Any SRC-4626 Vault that uses a Wrapped SIL SRC-20 as the asset MUST NOT implement SRC-7535. SRC-7535 only applies to native SIL.
Rationale
This standard was designed to maximize compatibility with SRC-4626 while minimizing additional opinionated details on the interface. Examples of this decision rationale are described below:
maintaining the redundant assets input to the deposit function while making its usage optional
not enforcing a relationship between msg.value and assets in a mint call
not enforcing any behaviors or lack thereof for fallback/__default__ methods, payability on additional vault functions, or handling SIL forcibly sent to the contract
All breaking implementation level changes with SRC-4626 are purely to accomodate for the usage of Sila or any native asset instead of an SRC-20 token.
Allowing assets Parameter to be Ignored in a Deposit
msg.value must always be passed anyway to fund a deposit, therefore it may as well be treated as the primary input number. Allowing assets to be used either forces a strict equality and extra unnecessary gas overhead for redundancy, or allows different values which could cause footguns and undefined behavior.
The last option which could work is to require that assets MUST be 0, but this still requires gas to enforce at the implementation level and can more easily be left unspecified, as the input is functionally ignorable in the spec as written.
Allowing msg.value to Not Equal assets Output in a Mint
There may be many cases where a user deposits slightly too much Sila in a mint call. In these cases, enforcing msg.value to equal assets would cause unnecessary reversions. It is up to the vault implementer to decide whether to refund or absorb any excess Sila, and up to depositors to deposit as close to the exact amount as possible.
Backwards Compatibility
SRC-7535 is fully backward compatible with SRC-4626 at the function interface level. Certain implementation behaviors are different due to the fact that SIL is not SRC-20 compliant, such as the priority of msg.value over assets.
It has no known compatibility issues with other standards.
Security Considerations
In addition to all security considerations of SRC-4626, there are security implications of having SIL as the Vault asset.
call vs send
Contracts should take care when using call to transfer SIL, as this allows additional reentrancy vulnerabilities and arbitrary code execution beyond what is possible with trusted SRC-20 tokens.
It is safer to simply send SIL with a small gas stipend.
Implementers should take extra precautions when deciding how to transfer SIL.
Forceful SIL transfers
SIL can be forced into any Vault through the SELFDESTRUCT opcode. Implementers should validate that this does not disrupt Vault accounting in any way.
Similarly, any additional payable methods should be checked to ensure they do not disrupt Vault accounting.
Wrapped SIL
Smart contract systems which implement SRC-4626 should consider only supporting SRC-20 underlying assets, and default to using a Wrapped SIL SRC-20 instead of implementing SRC-7535 for handling SIL.
The subtle differences between SRC-4626 and SRC-7535 can introduce code fragmentation and security concerns.
Cleaner use cases for SRC-7535 are SIL exclusive, such as Wrapped SIL and Liquid Staking Tokens.