tProof at a lower level
As briefly explained in the introduction section, the goal of tProof is to store an hash on the Blockchain (currently Ethereum), and eventually add more information to it. All those information are included inside an NFT:
- Hash - the hexadecimal representation (SHA-256 - 32 bytes) of the hash of the given file
- Name - a name representing the NFT. Useful to remember what the NFT represents for the owner
- Description - An extra field in case the user would like to add more information
- MIME-Type (optional) - The MIME-Type associated to the file. Available only for public files
- Storage Type (optional) - The storage used to publish the file. Available only for public files. Currently the only supported storage is Arweave.
- Verification status - true if the file is publicly verified, false otherwise
A user can decide to just generate one NFT (publish the hash on the blockchain) or also request the certification of the file, providing the public URL of the given file: this is what we call the Certification process.
Once generated the NFT with its hash, a user can then ask to assign a public URL to the NFT. This is done by calling the
verifyHashFileUrlfunction on the Router contract, and providing the following information
- ID of the NFT
- URL - formatted according to the Storage used
- Storage Type - a number representing the Storage Type among supported ones
- MIME Type - a number representing the MIME type among supported ones. 0 for undefined.
All those parameters are arrays, so that more certifications can be required within the same smart contract call.
- Storage Type: 0
- URL: the 43 characters representing a file on Arweave
The call provides the URL to a Chainlink Oracle, that downloads the file, evaluates the hash, and confirms (or refuse) the match between provided file URL and hash. In a later call, the Oracle returns the evaluated information, certifying (or not) the file hash on chain.
While we currently rely on a single, trusted Oracle, we've left open the option to have multiple oracles in the future, increasing the level of decentralization.
To certify an hash, each user needs to pay a basic certification fee: you can see the current value on our homepage or retrieve it from the Router smart contract (
MINT_PRICEpublic variable). That is the cost for the mint of an NFT containing the hash.
If you want also to make the file public, thus pairing a public URL to the hash, the cost of the operation is higher, and you can retrieve this extra cost by reading the variable
VERIFICATION_PRICE, or on our homepage.
A user can pay the mint cost + verification cost at the moment of minting, or in two separate transactions (maybe at a later time).
Once a verification cost is paid, the user has 14 days to provide the URL. After 14 days, the user needs to re-pay the verification.
Minting the proof and provide the File URL happens in two separate transactions. Looking at user experience, this would mean that the user has to wait for the file to be uploaded (and available) on Arweave to then perform the two calls. This in unacceptable, especially when gas prices are unpredictable.
This is why, if you look at our smart contracts' code, you'll notice in the Router
createProofsfunction (aka, minting function) the parameter
When minting, a delegator address can be added. This delegator will be the only wallet able to call the
verifyHashFileUrlfunction on behalf of the NFT owner.
If you've used our dApp, you noticed that you just perform one transaction (minting) and nothing more. Under the hood, the mint sets us as delegators, so that our backend procedures can call the
verifyHashFileUrlfunction once the file is uploaded on Arweave.
In this way, every project can integrate our solution within their protocol, preserving usability and user experience.
An NFT name, typically used as reference to the original file, can be edited anytime by calling the
editProofTitlefunction on the Router. This operation can be done by the NFT owner, not the delegator.
A custom title can be set directly in the minting function.
If you've paid for the public verification of a file URL, but after 14 days you have not been able to provide the URL, or if you passed a wrong verification URL and the verification failed, you need to re-run the verification process.
You can do that by calling the
extendVerificationfunction on the Router, paying the
VERIFICATION_PRICEfee and wait for the certification to complete again.