Come Concrete gestisce il NAV: il livello contabile dietro la DeFi istituzionale

Il Problema dei Vault in Tempo Reale

Ogni quota di un vault rappresenta un credito sugli asset sottostanti. La domanda è se il prezzo utilizzato per coniare e riscattare quelle quote sia effettivamente corretto.

Nella finanza tradizionale, il NAV(1) si muove lentamente. La maggior parte dei fondi utilizza un pricing forward, dove i depositi vengono regolati successivamente tramite finestre di ingresso in coda, limitando naturalmente il rischio di prezzi obsoleti.

La DeFi cambia tutto questo. Affinché le quote dei vault rimangano componibili tra mercati di prestito, loop di leverage e sistemi finanziari on-chain, i depositi devono avvenire atomicamente mentre le strategie sottostanti e i sistemi contabili si aggiornano in modo asincrono tra chain, piattaforme e ambienti di esecuzione.

Questo crea un pericoloso divario tra ciò che il vault possiede realmente e ciò che il vault crede di possedere.

Nel momento in cui il capitale può muoversi in modo continuo, il NAV smette di essere una funzione di reporting e diventa infrastruttura centrale. Ogni deposito, riscatto, ribilanciamento e regolamento dipende dall'integrità del prezzo utilizzato in quel preciso istante. Un NAV obsoleto non è un problema estetico; è un evento di trasferimento di valore.

Se i depositi vengono prezzati su saldi obsoleti, i nuovi utenti sovvenzionano i detentori esistenti. Se i riscatti vengono regolati su prezzi obsoleti, gli utenti che prelevano estraggono valore dal vault. E se una strategia subisce perdite prima che gli aggiornamenti del NAV le catturino, i nuovi depositi possono inconsapevolmente acquistare inventario danneggiato a prezzi pre-perdita. Nessuno di questi fallimenti appare nell'APY headline, ma sono importanti.

Questo è il problema infrastrutturale nascosto dietro la DeFi istituzionale, ed è esattamente il motivo per cui Concrete ha costruito un sistema di gestione del NAV in tempo reale progettato per la finanza asincrona on-chain.

La maggior parte dei sistemi di vault è stata costruita su questo presupposto: le strategie erano interamente on-chain e la generazione di rendimento era programmatica. Il capitale si muoveva attraverso smart contract, le posizioni si aggiornavano deterministicamente e la contabilità poteva essere codificata direttamente nel vault stesso. Finché le strategie vivevano interamente on-chain, il NAV rimaneva relativamente semplice da calcolare perché il vault aveva sempre visibilità immediata sulle sue posizioni e sui suoi saldi sottostanti.

Questo presupposto viene meno nel momento in cui i vault si evolvono oltre le strategie basate su smart contract.

I sistemi di vault moderni si basano sempre più su esecuzione attiva, allocazioni guidate dal curatore, distribuzione cross-chain e fonti di rendimento off-chain che non possono essere riflesse on-chain in tempo reale. Le strategie ora operano attraverso bridge, piattaforme di perpetual, money market, sistemi di restaking e pool di liquidità, tutti con diversi tempi di regolamento, ritardi di reporting e caratteristiche di liquidità. In alcuni casi, lo stato della posizione rilevante può dipendere da registri di custodia, dati della piattaforma, regolamento cross-chain o registri di esecuzione off-chain che non possono essere riflessi on-chain alla stessa velocità di un semplice saldo token.

Il risultato è che il capitale si muove in modo continuo mentre lo stato sottostante del vault si aggiorna in modo asincrono, creando un pericoloso divario tra ciò che il vault possiede realmente e ciò che il vault crede di possedere.

In quel divario, il valore si disperde.

La latenza dei prezzi non è un attrito operativo, è un trasferimento di rischio nascosto. Più velocemente si muove la DeFi, più importante diventa l'integrità contabile.

Gestione del NAV per la Finanza On-Chain

Concrete affronta il NAV come un problema di sistema, piuttosto che come un singolo oracolo o aggiornamento contabile. L'architettura combina modelli di smoothing, soglie di rischio dinamiche, verifica indipendente, controlli sui depositi e meccanismi di pausa automatizzati in un framework unificato progettato per mantenere accurato il pricing del vault anche durante condizioni di mercato volatili.

La prima sfida è il rumore. I dati grezzi sui prezzi sono intrinsecamente imperfetti. Ritardi dei bridge, API obsolete, dislocation temporanee di liquidità ed eventi di regolamento asincroni possono tutti distorcere la contabilità a breve termine. Concrete smussa le osservazioni del NAV utilizzando una media mobile esponenzialmente ponderata (EWMA), consentendo alle osservazioni recenti di avere più peso mentre filtra picchi isolati e anomalie transitorie.(2) L'obiettivo non è sopprimere la volatilità; è limitare l'influenza di irregolarità isolate dei dati sul pricing del vault.

Ma lo smoothing da solo non è sufficiente perché ogni vault si comporta in modo diverso. Una strategia di carry delta-neutral ha un profilo di volatilità completamente diverso da un vault di restaking con leverage. Un movimento di 50 punti base può essere insignificante per una strategia e catastrofico per un'altra. Concrete calibra ogni vault in modo indipendente collegando le soglie di pausa a misurazioni di volatilità rolling derivate da un modello di deviazione standard a due settimane.(3) Le soglie si restringono automaticamente durante i periodi stabili e si allargano durante ambienti volatili, consentendo alla gestione del rischio di adattarsi dinamicamente al comportamento della strategia sottostante invece di fare affidamento su presupposti statici.

Verifica Prima del Regolamento

Anche in questo caso, la velocità senza verifica non è infrastruttura istituzionale. Ogni aggiornamento del NAV all'interno di Concrete passa attraverso un processo di verifica a tre parti. Un Transaction Proposer calcola l'aggiornamento proposto utilizzando dati di strategia e contabilità. Un Independent Signer convalida l'aggiornamento rispetto a una fonte contabile separata. Infine, lo smart contract stesso rifiuta gli aggiornamenti al di fuori dei limiti contabili predefiniti.(4) Per progettazione, nessun singolo operatore, incluso Concrete, può modificare unilateralmente la contabilità del vault al di fuori dei limiti imposti dallo smart contract. Lo scopo del sistema non è semplicemente la ridondanza operativa; è ridurre il rischio che dati errati, report obsoleti o errori dell'operatore influenzino direttamente il livello di pricing con cui gli utenti transano.

L'integrità dei prezzi, tuttavia, è solo metà del problema. Anche sistemi contabili perfettamente verificati non possono eliminare la latenza tra gli eventi di mercato e gli aggiornamenti di regolamento.

La verifica garantisce che il NAV riportato sia corretto. L'integrità del regolamento garantisce che gli utenti transino contro quel NAV in modo equo mentre lo stato sottostante del vault continua ad aggiornarsi in modo asincrono.

L'obiettivo non è eliminare completamente la latenza. L'obiettivo è impedire che l'incertezza temporanea diventi una perdita di valore permanente.

Proteggere il Prossimo Depositante

Questo diventa più importante durante eventi di perdita materiale, che è dove la maggior parte dei sistemi di pausa della DeFi è fondamentalmente fraintesa. I meccanismi di pausa sono spesso inquadrati come salvaguardie operative che proteggono protocolli o operatori. In realtà, esistono per proteggere il prossimo depositante.

Se una strategia subisce una perdita materiale prima che il NAV si aggiorni completamente, il peggior risultato possibile è consentire a nuovi depositi di continuare ad entrare nel vault a prezzi obsoleti. Quegli utenti stanno effettivamente acquistando inventario danneggiato senza rendersene conto. L'architettura di pausa di Concrete è progettata specificamente per questo scenario. Quando le deviazioni tra il livello di osservazione live e il modello di pricing smussato superano le soglie aggiustate per la volatilità, il sistema è progettato per fermare i depositi fino a quando l'integrità dei prezzi non viene ripristinata.(5) Lo scopo non è la convenienza operativa; è ridurre il rischio che le perdite vengano socializzate involontariamente tra i partecipanti.

I prelievi introducono lo stesso problema al contrario. Se il capitale rimane impiegato dopo che è stata avviata una richiesta di prelievo, sta ancora generando rendimenti ed è ancora esposto al rischio. Trattare gli utenti come usciti prima che le posizioni siano effettivamente liquidate crea una discrepanza tra esposizione economica e realtà contabile.

L'architettura di vault asincrono di Concrete utilizza code di prelievo epocali compatibili con ERC-4626 che regolano i riscatti contro il NAV al momento del regolamento, non al momento della richiesta.(6) Il principio è semplice: se i fondi sono ancora esposti al rischio della strategia, devono anche rimanere esposti alle conseguenti variazioni del NAV. Qualsiasi altra cosa crea opportunità di arbitraggio e trasferimento di valore iniquo tra i partecipanti.

Il Prodotto è lo Stack

Ciò che conta non è nessun singolo livello di controllo, ma come i livelli si rafforzano a vicenda. Lo smoothing senza soglie adattive diventa troppo rigido. Le soglie senza verifica introducono rischio operativo. La verifica senza controlli sui depositi espone ancora gli utenti durante le finestre di latenza. I limiti di deposito senza sistemi di pausa consentono ancora eventi di pricing danneggiato. E i sistemi di pausa senza un'architettura di prelievo coerente perdono ancora valore al momento del riscatto.

Il prodotto non è l'EWMA. Il prodotto non sono i limiti di deposito. Il prodotto non è la contabilità automatizzata.

Il prodotto è lo stack.

Gli allocatori istituzionali non valutano i vault esclusivamente in base al rendimento. Valutano l'integrità contabile, i controlli operativi, l'accuratezza dei prezzi e la progettazione della mitigazione delle perdite. Questo è il livello infrastrutturale necessario affinché la DeFi maturi oltre i flussi di capitale speculativo e si evolva in infrastruttura finanziaria programmabile in grado di supportare capitale su scala istituzionale.

Il sistema di Concrete è progettato in modo che gli aggiornamenti del NAV siano verificati in modo indipendente, le anomalie dei prezzi siano filtrate prima del regolamento, l'esposizione ai depositi sia limitata dinamicamente, gli eventi di perdita materiale attivino meccanismi di pausa sui nuovi afflussi e i prelievi siano regolati su stati contabili live piuttosto che su snapshot obsoleti. Questi sistemi non sono funzionalità opzionali aggiunte ai vault successivamente. Sono requisiti fondamentali per rendere la finanza programmabile affidabile su larga scala.

Il Futuro dell'Infrastruttura dei Vault

La DeFi ha risolto la trasparenza prima di risolvere la contabilità. Ora questo sta cambiando.

Man mano che i vault si evolvono in infrastruttura finanziaria programmabile che opera attraverso chain, strategie e livelli di liquidità, la qualità dell'infrastruttura diventa più importante dell'APY headline. La prossima fase della DeFi non sarà definita da chi riporta il rendimento più velocemente. Sarà definita da chi può rendere affidabili quei numeri.

Il NAV in tempo reale non è semplicemente un miglioramento dell'UX. È un'infrastruttura fondamentale per il capitale istituzionale. Perché più velocemente il capitale si muove on-chain, più importante diventa l'integrità contabile.

I vault non sono più involucri di rendimento passivi. Sono sistemi finanziari programmabili, e i sistemi finanziari programmabili richiedono fiducia programmabile.

Questo articolo è solo a scopo informativo e non costituisce consulenza in materia di investimenti, legale, fiscale, finanziaria, né un'offerta o sollecitazione di alcun tipo. Le descrizioni dell'architettura, dei controlli e degli obiettivi di progettazione di Concrete sono illustrative; non eliminano i rischi associati a smart contract, protocolli DeFi, condizioni di mercato, guasti di oracoli o dati, guasti operativi, infrastrutture di terze parti o performance della controparte. Concrete non garantisce che qualsiasi rendimento target, accuratezza del NAV, comportamento di pausa o altro risultato del sistema sarà raggiunto. Le dichiarazioni previsionali riflettono le attuali aspettative di Concrete e non sono garanzie di risultati futuri. La partecipazione ai vault di Concrete comporta rischi, incluso il rischio di perdita totale. Per le informative complete sui rischi, consultare https://concrete.xyz/disclaimershttps://concrete.xyz/disclaimers).

1. In questo articolo, "NAV" si riferisce al valore contabile operativo utilizzato per prezzare le quote del vault, i depositi, i riscatti e il regolamento a livello di strategia. Può differire dal NAV del bilancio, dai registri del custode o dai valori del protocollo di terze parti e può essere soggetto a metodologia e tempistiche specifiche del vault.

1. Una media mobile esponenzialmente ponderata dà più peso alle osservazioni recenti pur incorporando dati più vecchi. Parametri specifici, inclusi il tasso di decadimento e le finestre di osservazione, sono calibrati per ogni vault e possono essere aggiornati da Concrete nel tempo in base alle caratteristiche della strategia, alle condizioni di mercato e ai dati operativi. Lo smoothing EWMA riduce l'influenza delle anomalie di prezzo a breve termine ma non elimina il rischio di prezzo.

1. Le finestre di volatilità, le larghezze delle soglie e i parametri di pausa sono calibrati per ogni vault, sono soggetti a modifiche a discrezione di Concrete e dipendono dall'accuratezza dei dati di input. Nessun modello di soglia può anticipare ogni condizione di mercato.

1. I ruoli descritti (Transaction Proposer, Independent Signer e convalida on-chain) operano all'interno degli smart contract del vault di Concrete e sono soggetti a controlli multisig e timelock. La verifica riduce ma non elimina il rischio di aggiornamenti NAV errati, inclusi i rischi derivanti da chiavi compromesse, dati di input errati o vulnerabilità degli smart contract. La cronologia degli audit di Concrete è disponibile su docs.concrete.xyz/audits.

1. Il comportamento di pausa dipende da un'accurata calibrazione delle soglie e dall'accuratezza del livello di osservazione sottostante. Le pause potrebbero non essere attivate in tutti gli scenari di perdita e la progettazione è intesa a ridurre, non eliminare, il rischio che i nuovi depositanti transino a prezzi obsoleti.

1. I vault di Concrete sono costruiti secondo lo standard di vault ERC-4626, con estensioni di code di prelievo asincrone basate su epoche implementate a livello di contratto. I tempi di regolamento dipendono dal profilo di liquidità della strategia sottostante e possono essere soggetti a limiti a livello di vault, eventi di sospensione e altri termini stabiliti nella documentazione applicabile del vault.