The "oracles" are systems in charge of acquiring data, possibly normalizing them and then inserting them into a distributed ledger. Usually this activity triggers the activation of a Smart contract, therefore an uninterrupted process that can also manage economic transactions. The execution of Smart Contracts is uninterrupted and managed in a decentralized way, making it an extremely secure computational system. However, if the data entered by Oracle is incorrect or partial or completely absent, the Smarcontract will produce unwanted effects or will not have any execution. Furthermore, oracles usually do not operate in a bidirectional way, therefore they do not acquire the data produced by the Smart Contracts and then publish them on other destinations. The system that the Cyronclad network supervisor supplies is an Oracle, but not just an Oracle, but a Distributed Oracle or dOra. The distributed organization of the dOra system increases the level of security and quality of the managed data. In fact, it is virtually impossible to compromise the execution of the dOra system or produce false data that appears to be published by the real system. Finally, since the dOra system performs a series of sophisticated mathematical procedures to produce digital signatures in a distributed way, we have equipped it with the ability to perform arbitrary tasks chosen by the customer, possibly making the activation of a smart contract unnecessary.

dOra è un un Oracolo distribuito, ovvero un sistema computazionale programmabile in cui il processore è costituito da un comitato di nodi. Nessuno dei nodi del comitato è autonomo nel produrre un dato o svolgere un compito (ad esempio immettere dati in un DLT) senza che la maggioranza dei nodi del comitato abbia prodotto lo stesso dato o sia predisposta a svolgere quel compito

I dati prodotti da dOra sono firmati dal comitato con un processo di firma, definito "distribuito" e "a soglia". Il processo di firma è distribuito perchè nessuno dei nodi conosce la chiave privata con cui poter produrre una firma valida. La stessa chiave pubblica è prodotta con un processo distribuito: ogni nodo crea una propria chiave privata e, seguendo un procedimento standard chiamato Distributed Key Generagion, scambiando informazione non critiche, ottiene dagli altri nodi le informazioni necessarie per calcolare la una chiave pubblica. Avendo le stesse informazioni ogni nodo produce la stessa chiave. E' un procedimento di fima detto "a soglia" in quanto per produrre una firma valida occorre che un minim numero di nodi del comitato, la soglia, abbia lo stesso dato. Ogni produce stessa firma parziale usando la propria chiave privata e la condivide con gli altri nodi. Se almeno un numero di nodi superiore alla soglia ha firmato lo stesso dato e condiviso la firma parziale allora, integrando le firme parziali, ogni nodo è in grado calcolare la firma comunque, valida per la chiave pubblica comunue.

La firma prodotta dal comitato è un dato e come ogni altro dato nel sistema Cyronclad deve essere verificabile, non solo per correttezza formale, ma per "paternità". La paternità di un dato ci permette infatti di valutare la significativitò del dato. Per ottenere questa informazioni nel sistema dOra ogni soggetto è indentificato con un Identificativo Digitale o DID, secondo l'omonicmo standard del consorzion W3C. Un DID è rappresentato con una URL che permette di ottenere un DID Document, una sorta di documento di idendità, che contiene le inforazioni necessarie a validare firme prodotte dal soggetto identificato, quindi certificare la paternità dei dati che produce. Anche il comitato del sistema dOra deve avere un DID e pertanto la prima operazione che il comitato svolge quando viene attivato è proprio creare il proprio DID e pubblicare il relativo DID Document. Qualunque dato pubblicato da comitato conterrà il suo DID mediante il quale è possibile ottenere il DID Document, quindi la chiave pubblica con cui validare la firma del dato.

Uno dei possibili modi con cui un server può essere attaccato allo scopo di creare un disservizio è il "Denay of Service". Si tratta di una tecnica di attacco che ha l'obiettivo di saturare la banda del colelgamento di rete del server, o di saturare le sue risorse operative. L'attacco avviene inviando al server una quantità anomala di richieste, anche banali, provocando un sovraccarico che è produce effetti equivalenti al distacco del server dalla rete o al suo spegniento. Per rendere il sistema dOra immune da questi tipi di attacco, i nodi e lo stesso comitato non usano il protocollo TCP/IP per comunicare tra loro e con i client, ovvero il loro indirizzo di rete non è pubblicato e pertanto non possono subire un attacco DOS. I nodi comunicano usando la rete IOTA come secure transport layer. La rete IOTA è composta da migliaia di nodi che si interconnettono in modo dinamico tra loro. Nessuno può sapere a quale nodo IOTA è collegato un nodo dOra e pertanto non è possibile pianificare un attacco. Inoltre, ogni nodo dOra può usare più nodi IOTA per pubblicare i messaggi destinati agli altri nodi e pertanto il sistema di comunicazione è altamente ridondante. Inoltre, la stessa rete IOTA garantisce che il messaggio pubblicato da un nodo sia quasi istantaneamente replicato su tutti gli altri nodi della rete. Ciò rende impossibile anche impedire a un nodo di ricevere un messaggio perchè sarà recuperabile da qualsiasi altro nodo della rete. L'indirizzamento dei messaggi, a garanzia che vengano ricevuti dal detinatario, è basato sull'identità, ovvero il DID: ogno nodo dOra è pertanto in ascoto su un nodo IOTA per ogni messaggio pubblicato da altri nodi che abbia un "tag" con il proprio DID o il DID del comitato a cui appartiene. Quindi anche l'invio dei messaggi a un comitato dOra, contenenti richieste di esecuzione di task, è immune da attacchi, perchè non vi è un singolo soggetto preposto a riceverli, ma tutti i nodi del comutato lo ricevereanno contemporaneamente.