Builder Spotlight: YieldSense

Builder Spotlight: come YieldSense porta l’esecuzione verificata dall’hardware nella DeFi su Base

Quando un protocollo DeFi vuole automatizzare qualcosa, che si tratti di riaggiungere le ricompense alla posizione, ribilanciare una griglia o attivare uno stop-loss, lo schema predefinito è quasi sempre lo stesso: un keeper bot su un server centralizzato, un singolo hot wallet che firma ogni transazione e, da qualche parte, un file di configurazione che contiene in chiaro i parametri della strategia.

 

YieldSense, sviluppato da Malik Huzaifa, elimina del tutto quel singolo punto di guasto. Costruito su Base e basato sulla rete decentralizzata di Acurast, fa sì che ogni decisione, ogni firma e ogni parametro della strategia risiedano all’interno di un Trusted Execution Environment di Acurast. Il contratto on-chain su Base accetta solo transazioni firmate da un worker attestato.

 

Questo post ripercorre brevemente cosa è stato costruito, come è integrato Acurast e cosa indica sulla direzione dell’automazione DeFi.

 

Il progetto in breve

 

01 / Il problema del keeper centralizzato

Quattro ipotesi di fiducia che l’automazione DeFi ha accettato in silenzio.

Oggi la maggior parte dell’automazione DeFi eredita le stesse quattro debolezze. Nessuna è fondamentale. Sono solo l’eredità di un’epoca in cui non esisteva un buon modo per eseguire logica off-chain con integrità on-chain.

 

02 / Come i TEE di Acurast cambiano il modello

Logica decisionale e firma, entrambe chiuse in un’enclave.

YieldSense usa la rete TEE di Acurast come intero livello decisionale e di firma. L’utente firma un intent EIP-712 nella dashboard, impostando i propri parametri di strategia confidenziali: stop-loss, slippage, intervallo di ottimizzazione, heartbeat. Il payload cifrato viene inviato a un worker TEE di Acurast.

 

All’interno dell’enclave, lo strategy engine recupera i dati su APR, gas e prezzi direttamente dagli RPC di Base, esegue la logica decisionale e procede solo se le ricompense attese coprono più del 150% del costo del gas. Se l’operazione supera questa soglia, il TEE firma la transazione con una chiave P-256 legata all’hardware che non lascia mai l’enclave.

 

Il contratto YieldSenseKeeper su Base verifica poi l’attestazione hardware prima di avviare l’esecuzione. Tutto ciò che non è firmato da un worker Acurast in whitelist viene rifiutato subito.

 

L’effetto complessivo è semplice: i parametri della strategia non lasciano mai l’enclave, le chiavi di firma non toccano mai un server e il contratto on-chain ha una prova crittografica dell’origine di ogni transazione. Questo elimina il singolo punto di guasto, mantiene riservata la strategia e rende verificabile on-chain ogni fase dell’esecuzione.

L’architettura a tre piani. L’intent dell’utente scorre dall’alto verso il basso, attraverso l’enclave, fino al regolamento on-chain attestato.

 

03 / Cosa è attivo oggi

Un autocompounder Aerodrome USDC/AERO che esegue l’intera pipeline TEE.

 

L’MVP su Mainnet esegue su Base un autocompounder Aerodrome USDC/AERO, cioè un contratto che riaggiunge automaticamente alla posizione le ricompense raccolte, interamente gestito dalla pipeline TEE di Acurast. Acquisizione di dati APR reali, validazione reale del gas, harvest reali, firme attestate reali. La dashboard mostra tutto: posizioni nette, stime delle ricompense, ottimizzazione del gas e un Guardian Ledger live di ogni azione del TEE.

 

Sotto il cofano, a ogni ciclo il keeper esegue la stessa sequenza in cinque fasi. Nessuna fase avanza se la precedente non produce un risultato con attestazione hardware.

Il ciclo di harvest. Ogni fase riceve l’attestazione hardware prima di avanzare.

Ogni azione finisce nel Guardian Ledger nel momento in cui avviene, insieme all’indirizzo hardware che l’ha firmata.

 

 

Ecco come appare l’attestazione hardware in tempo reale: ogni esecuzione e attestazione etichettata, con marca temporale e collegata a uno specifico indirizzo di Processor Acurast.

 

Due contratti gestiscono il lato on-chain:

 

04 / Una base verificabile per il grid trading

Segnali grid con attestazione hardware, in attesa dell’esecuzione live.

Il lato grid trading di YieldSense è volutamente prudente, e vale la pena capirlo con precisione.

 

Al momento il Grid Keeper funziona come un esecutore firmato attivato dal prezzo. Il TEE monitora un pool configurato (attualmente AERO/USDC), confronta il prezzo live con livelli di riferimento fissi definiti in GRID_CONFIG_JSON e, quando un prezzo si muove oltre un triggerPercent impostato, l’enclave calcola il delta teorico di PnL per quel livello della griglia e firma una prova crittografica dell’azione. Il Processor chiama executeTrade() sul contratto keeper, e il contratto registra l’operazione on-chain come evento verificabile.

 

Cosa non fa ancora: interagire con i router DEX, gestire l’inventario dei token o spostare saldi tra utenti. La logica grid produce log di audit con attestazione hardware, non modifiche reali delle posizioni.

 

È una scelta voluta. Prima che YieldSense muova inventario reale, il team voleva dimostrare che l’enclave è in grado di identificare, valutare e firmare correttamente i trigger delle operazioni, con ogni azione registrata on-chain come evento con attestazione hardware. Il Guardian Ledger offre agli auditor un registro completo di ciò che l’agente ha visto, deciso e firmato. L’esecuzione live è il naturale passo successivo sulla stessa base.

 

05 / Cosa dice tutto questo su Acurast per la DeFi

Uno schema che va oltre la raccolta delle ricompense.

YieldSense sta facendo qualcosa di più che costruire un singolo prodotto DeFi. Sta mostrando che le ipotesi di fiducia che l’automazione DeFi si porta dietro da anni non sono strutturali, ma circostanziali.

 

Lo stesso schema che YieldSense usa per riaggiungere le ricompense e per i segnali grid si estende direttamente ad altre primitive: agenti IA che gestiscono fondi entro vincoli dimostrabili, regolamento cross-chain con logica off-chain attestata, attestazione di oracoli con firma basata sull’hardware, pagamenti condizionali attivati da eventi verificati nell’enclave. Nessuna di queste richiede un nuovo framework. Serve che il livello dei keeper sia a fiducia minimizzata. È il livello che forniscono i TEE di Acurast.

 

Lo sviluppatore

YieldSense è sviluppato da Malik Huzaifa, software architect e blockchain engineer che si occupa di sistemi autonomi a fiducia minimizzata. Il progetto nasce dalla sua ricerca sui TEE e sulla loro applicazione per decentralizzare strategie DeFi complesse. È attivo su X e LinkedIn.

 

Questa è la rete a cui si collega YieldSense. Ogni dato qui sopra si aggiorna man mano che la rete cresce.