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.