The NAV oracle
Takes the account value from Binance and turns it into an independently verified NAV.
What the oracle does:
Reads each vault's value from Binance, computes NAV per share, and publishes it on-chain, continuously. The figure is not trusted on MakeBanc's say-so: it is independently verified, by a consensus mechanism and a human reviewer, before it touches the vault. Deterministic: same inputs, same NAV.
Input sources:
Binance account data. The live state of each SMA, which is a Binance sub-account: cash holdings, open positions at mark price, accrued funding payments, margin requirements. This is the source of the NAV figure, read directly from the Binance API. Ceffu is the custodian that holds the assets, but the Binance sub-account value used for NAV comes from the Binance API, not from Ceffu.
Internal accruals. Accrued platform and insurance fees, performance fees, and other accruals between settlement events. Subtracted from gross value to compute net value attributable to shareholders.
The computation:
For each vault, at each NAV update:
- Pull the latest Binance sub-account value for the SMA from the Binance API. Verify timestamp.
- Compute total vault value: cash + open positions at mark + accrued income.
- Subtract accrued unsettled fees.
- Divide by total shares outstanding (excluding shares pending issuance).
- Result: NAV per share.
The arithmetic is straightforward. Reliability comes from input validation, not algorithmic complexity.
Independent verification:
The NAV doesn't just get published. It gets verified independently, two ways, before it touches the vault.
Consensus mechanism. Chainlink runs a CRE DON (Decentralised Oracle Network) with a 16-node consensus mechanism. MakeBanc submits the NAV read from Binance. The DON verifies it against independent data sources and sends back only an approve or reject signal. No edits are allowed; it's a binary gate, not a negotiation.
Human review. A human reviewer also checks the NAV before it is finalised. Like the DON, the reviewer can only approve or reject the figure. They cannot edit it, adjust it, or influence the value in any way. It is the same binary gate, applied by a person as a second, independent line of defence against a bad read.
If either the DON or the human reviewer rejects, the NAV is not published. The vault continues operating at the most recent verified NAV until the discrepancy is resolved.
This means no single party (not MakeBanc, not any individual node asset manager, not the reviewer) can push a manipulated valuation on-chain. The figure comes from Binance, sixteen independent nodes have to agree, and a human can only ever pass or fail it.
Publication on-chain:
Once both the Chainlink DON and the human reviewer approve, the NAV is published to the vault contract on Base. The vault validates the signature and records it.
Multiple NAVs per day. The most recent is used for:
- Position values on your dashboard
- Share issuance at settlement events
- Share redemption at redemption windows
- Accrued performance fee calculations
Historical NAVs are retained in the contract for audit.
What the oracle does not do:
Pick positions (the asset manager does). Decide what NAV should be (it computes from inputs). Endorse the strategy (a falling NAV is reported honestly).
Input validation:
Timestamp validation. Stale data triggers fallback to the most recent valid data and a flag on the resulting NAV.
Cross-source validation. Position values from the Binance API are cross-checked against independent mark prices. Material discrepancies trigger an alert.
Reasonableness validation. NAV per share moving more than ~5% in a single update triggers an alert. The update is held pending review.
These catch input errors, not mask performance. A genuine 10% loss triggers the alert; the move is reviewed and confirmed before publication.
What you see:
Latest NAV on your dashboard. History on the strategy page. Any flags (stale data, discrepancy, reasonableness alert). Flags are never hidden.
What asset managers see:
Same NAV, plus inputs: cash balance, position values, accrued fees. Verifiable against their own records. Disputes go through the platform's dispute framework.
Restatement:
Sometimes an input source corrects a value after the fact. The oracle recalculates the affected NAV. The vault supports restatement: a new NAV for a previous timestamp, marked accordingly.
Restatements affect:
- Share counts: recalculated if the restatement covers a settlement event. Over- or under-issuance settles in the next event.
- Position values: displayed at the restated NAV.
- Performance fee calculations: recalculated if the restatement falls in a performance period. Crystallised fees may be adjusted.
You and asset managers have ten business days to query a restated NAV before it's treated as final.
What if the oracle fails:
Fails to publish: most recent valid NAV continues in use. Monitoring triggers fallback, then incident response.
Publishes incorrect NAV: dispute and restatement framework handles it. Historical NAVs retained for auditable correction.
Compromised: governance pauses the vault. Documented in Self-custody model.
Why this matters:
NAV determines share issuance, redemption, performance fees, and every position value you see. The oracle computes NAV deterministically from auditable inputs, with a defined dispute and restatement process. The calculation methodology, inputs, and outputs are publicly verifiable.