docs: ADR 0004 — hub-and-spoke NAV pattern evaluation#29
Draft
0xgleb wants to merge 2 commits into
Draft
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
2bd571a to
e6a7ca2
Compare
43e9f9b to
60e0ffa
Compare
Evaluate whether to re-architect NAV management to follow the LayerZero x Centrifuge report's multi-chain pattern. The report solves the inverse problem (propagate a trusted NAV outward to share-token spokes) to ours (ingest untrusted off-Solana value inward to compute NAV), so most of it does not apply. Split the evaluation into two directions: adopt the inbound accounting discipline (double-entry ledger, reconcile-or-floor epoch gate, proof-gated in-transit token) because it improves NAV correctness within the existing trust model; decline outbound multi-chain share distribution absent a product trigger, because it adds a stale-price consistency gap and a second cross-chain trust surface without improving valuation. No pricing formula or trust boundary in ADRs 0001-0003 changes.
e6a7ca2 to
9c7764d
Compare
60e0ffa to
b813171
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Asked whether we can re-architect NAV management to follow the LayerZero x
Centrifuge report's multi-chain pattern, and whether it would help. The two
designs sound identical but solve inverse problems: the report propagates a
trusted NAV outward to share-token spokes (price consistency); we ingest
untrusted off-Solana value inward to compute NAV (trust-minimized valuation).
Worth a written decision so it is not re-litigated later.
Solution
ADR 0004 splits the report's pattern into two directions with opposite value
signs:
(turns ADR 0001's "maintenance bug mis-prices shares" residual into an
on-chain
assets = liabilities + equityassertion), a reconcile-or-floorepoch-NAV gate (we floor rather than wait, because freezing redemption is
forbidden), and the proof-gated in-transit token from the stacked ADR 0002
refinement. Optional unifying frame: model the whole tier system as one
ledger — Tier 1 native entries, Tier 2 capped/floored liability tokens,
in-transit proof-gated receipts, Tier 3 side-pocket claims.
Multi-chain investor access does not improve NAV; it re-introduces the
report's stale-price "consistency gap" (the 2003 mutual-fund scandal as a
cross-chain artifact) plus a second cross-chain trust surface beside the
inbound Wormhole Queries read. Pins the constraints any future
multi-chain-shares work must meet.
No pricing formula or trust boundary in ADRs 0001–0003 changes. Stacked on the
ADR 0002 refinement branch (#28), itself stacked on #11.