Smart Contracts overview

Before presenting the global structure of smart contracts, a technical note about how we decided to develop them. While initially we were working on Upgradable smart contracts, we fiannly opted for multiple contracts that are non-upgradable. This to guarantee the immutability of the core parts of the service over time, especially for those integrating it in business processes that cannot accept multiple payments.

While core elements are immutable, we've set up a degree of flexibility around potential new services that can be added over time.

Currently, all the management of the contracts is under responsibility of the core team. In the future, a DAO with voting power will be set up.

Factory and registry

To mint NFTs and manage the certification of a File URL with a hash, we have two contracts:

• NFTFactory.sol - responsible of generating the NFTs, representing the file hash on the blockchain, with the storage of other core NFT details

• HashRegistry.sol - manages the certification of the File URL - Hash pair (using Chainlink), with a degree of flexibility on a few parameters. This contract is used only if your files are made Publicly accessible in the certification process

So, if you need to generate a simple proof, you can directly interact with NFTFactory. If you want to publish your file, you need to interact with both. This makes everything more complex, leading to the next contract: Router

Router: simplify interaction with tProof

The Router contract will be your main entry point for almost any of the interactions you may want. Through the router you'll be able to:

• request the creation of a new proof (with private or public file)

• start the certification of a File URL

• extend the validity of a file URL certification

• edit the Name of an NFT

These are the functions that simplifies the interaction and covers 99% of the use cases. More fine-grained options are available by directly interacting with lower-level contracts.

URL storage and verification

Since in the future we can have, ideally, a wider range of supported storage, we decided to manage the storage of each of them with separate contracts

HashRegistryStorageType_ArweaveV1.sol is the contract that manages the storage for files published on Arweave.

To manage the verification process (call to Chainlink Oracle and reply), UrlVerifierRouter.sol has all the required functions.

Represent the tProof

The last contract of our ecosystem is NFTTokenUriGenerator.sol. This contracts is in charge of generating the TokenURI and can be edited over time, to update its logic with the evolution of our product.