docs: initial managed vault specs#52
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Two things we need add to the spec. Yield accounting to mNAV
Explain NAV accounting for inflight funds. Reference comes from the larger PR. |
|
Update the spec to only have one v2 vault. Unique authority for the dollar vault. |
|
Specify a mechanism for rotating the manager. Remove IBC from the spec for now. |
Clarify that there is only 1 vault and multiple remote positions
Some clarifications
Spec for the NAV oracle
| - **Concentration Limits**: No single position > X% of total vault | ||
| - **Chain Limits**: Maximum exposure per blockchain | ||
| - **Approved Vaults Only**: Only deploy to pre-approved vault addresses |
There was a problem hiding this comment.
are this limits managed by the vault manager or the noble authority?
There was a problem hiding this comment.
Does the Noble team have a preference for who gets to approve the deployment addresses?
In most systems we've built we have had a dual control mechanism where the customer or another party is involved in decisions to add or remove targe positions.
I think it's a good pattern but NASD or Noble authority could work here.
Co-authored-by: Justin Tieri <37750742+jtieri@users.noreply.github.com>
…ation-for-emergency-mode docs: describe emergency mode in vaults v2 overview
There was a problem hiding this comment.
This file looks fine for now but would like to make sure it stays up-to-date with any changes made as we finalize the Protobuf definitions in the following PR 😄
There was a problem hiding this comment.
There was a problem hiding this comment.
I think overall this is a good start, but would like to remove anything unneeded that comes up during development. We should optimize for sending as few bytes over the wire as possible 😄
Co-authored-by: John Letey <j@letey.de>
Co-authored-by: John Letey <j@letey.de>
Co-authored-by: John Letey <j@letey.de>
Co-authored-by: John Letey <j@letey.de>
Co-authored-by: John Letey <j@letey.de>
Co-authored-by: John Letey <j@letey.de>
Co-authored-by: John Letey <j@letey.de>
johnletey
left a comment
There was a problem hiding this comment.
Merging this into the feature branch, will revisit in a follow on PR if this differs from the actual implementation!
Initial spec for the managed vault.
This pull request introduces comprehensive documentation for the Vaults V2 system, covering its architecture, state management, and supported query endpoints. The changes provide a clear overview of the multi-chain yield optimization approach, detail the on-chain state structures, and specify the API for interacting with the vaults. The documentation is organized into three new spec files: an overview, state definitions, and query endpoints.