# Introduction {% hint style="warning" %} This documentation is currently WIP! If you find some sections incomplete, please get in contact with us on [Twitter](httos://twitter.com/tproofio) or drop an [email](mailto:team@tproof.io)! {% endhint %} ![](https://67800616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F86XUzqXXIOuFawN8kl3C%2Fuploads%2F1I6wFVOR3AV3nwFr5UV7%2FtProof%20Logo%20Sticker%20w%20claim.png?alt=media\&token=842b67e1-0f88-4924-948a-6b426c17b314) **tProof** is a **Decentralize Proof of Timestamp** service that you can use to certify the existence of a file at a certain point in time. Proving a file existed at a given timestamp, and was available to a specific user is a crucial task in different areas. Let's think about healthcare, insurances, copyright infringement, law compliance for companies and much more. Since blockchain early days, proof of timestamp has been a widely debated use case. Despite that, a tool to solve this task, that was at the same time decentralized and easy to use, hasn't been built yet. tProof not only aims to solve this task easily, it also aims to do it with an independent, open-source, trustless and decentralized service, like all Web3 solutions should be. ### Decentralized, free to use service Adopting Web3 leading technologies and solutions, such as **Ethereum** as chain storage, **ChainLink** Oracles to verify hash/file matching, and **Arweave** storage, to permanently store published files, we ensure that the service does not rely on a centralized environment, and it can be integrated wherever its needed. To better understand how it works, we highly suggest you to read this documentation in both its initial sections: [How it works](/how-it-works) and [Certify your first file](/certify-your-first-file). A more technical description follows to better understand the core procedures. That part is targeted to those that would like to automate the interaction with our solution, or integrate our features within their projects. # How it works ## File and Hash **Hashing** is a mathematical technique that has been used for decades. You can hash almost anything: a character, text, document, or webpage. The same input (aka, the same file) always leads to the same output, and if you change 1 single bit in the original input, then the hash changes completely (not slightly). Although the input can be big or small, an outputted **hash always has the same length**. Moreover, the operation is one way: it’s easy to go from an input to the hash, but it’s hardly impossible to go from a hash to the input. Given this short introduction, we can now say that, given a file `FileName.ext`, and given an hash function, you can always generate the hash of `FileName.ext`, and that hash is always the same, as long as the file `FileName.ext` does not change, even for a single bit. Hash is typically represented in hexadecimal format, something like: `0xab34d2f8...c98745`. ![File to hash process](https://67800616-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F86XUzqXXIOuFawN8kl3C%2Fuploads%2FJIp0aIPJfQg0uRURmjV6%2FGeneral%20flow%20idea-Page-4.drawio%20\(1\).png?alt=media\&token=6c185569-ac02-448d-ab80-26d7e283cb2d) An **hash is a very short representation of the file**. It has lost the meaning of its content, but it's uniquely connected to the original file. Using an hashing function such as SHA-256, the probability of having two files generating the same hash is so small, that we can ignore it. ## Hash and Blockchains When you publish something on a blockchain, such as Ethereum, the data published are included in a block and immutably stored. A block is minted at a given time, stored in the blockchain too, and it's verified by a large number of validators. When you **publish an hash**, you're saying that the file existed prior to the block in which the hash is registered. If in the future someone challenges you saying you created a specific file after a certain date, you can easily prove he's wrong by showing the hash stored on blockchain. ## Blockchains and NFTs A Non-Fungible Token (NFT) is a representation of something that cannot be divided. In tProof, each hash published on blockchain is represented by an NFT, with the following core metadata: * the hash representing the file * a name (optional), to easily identify it * a description (optional) to better understand it's content * a file URL (optional) to view the file that generated the hash Being a standard ERC-721 token, the NFT can be transferred, sold and even burned. ## From file to hash As you'll be able to see in the next section of this guide ([Certify your first file](/certify-your-first-file)), using our Web App you can easily store the hash of a single file on Ethereum, and receive an NFT representing the given hash. These are the steps a user has to follow * Visiting our Web App on app.tproof.io * Connect wallet. The wallet must have a minimum amount of native token balance (ETH or MATIC) to send the transaction * Select the file(s) to certify * Decide whether to publicly publish the file or not (see later for details) * Click on "*Certify*" and sign the Ethereum transaction * Once the transaction has been approved, an NFT representing the hash will be available in the wallet In case the user would like to **publish the file**, so matching the hash with a public file URL,the cost of the operation is a little bit higher due to the process required to certify that the provided file matches the published hash. As we're a decentralized solution, to achieve this we use **ChainLink oracles**, and a more detail explanation can be found in the technical section. ### Publish the file When you publish the hash on chain, you can then decide whether to **combine the file URL with the hash**, or just keep the hash. We understand not all the files can be made public, and not publishing the file does not affect the validity of the hash. With a public file, though, anyone can both see the file connected to it, and always certify it's the one matching the given hash, without asking you for it. For true immutability of published files, we use [Arweave network](https://www.arweave.org/) as primary storage layer. If you certify a file using our UI, and you decide to publish it, we'll take care of uploading it on Arweave network for you, with no extra costs for you. As mentioned above, to certify the match between a file URL and its hash, and to then include the URL inside the NFT, we'll use the power of **ChainLink Oracles**, that will certify the hash of a given file , available at a given URL, matches the one published on chain. ### Multiple files If you have more than one file to certify, you have two options: * certify files **separately**, producing one NFT for each file * produce a **combined .zip file** and certify it The result is exactly the same, as long as the ZIP file respects the current size limitations we've put in place (see [Current Known Limitations](#undefined)). With one large ZIP file, you'll pay just one verification fee, but you cannot treat them separately. Just remember to not edit (add/remove files) from the ZIP you have certified, as this operation changes the file, along with its hash. As always, the solution depends on your needs. What matters is that, either way fully certify your files! ### Current known limitations As of now, we've set a **small amount of limitations** to avoid network ingestion. If you are working on a custom project and would like to raise them, please contact us! * Max file size is **100MB**. Higher size won't pass the ChainLink Oracle verification. If you're not planning to make the file public, then you don't have any size limitation, as long as you're able to compute the hash * You cannot create more than 100 NFTs with a single call, thus verify more than **100 files** **with a single operation** # Advantages Compared to other solutions to generate proofs of timestamps (both off-chain and on-chain), you can find in tProof the following main advantages: * **Decentralized**: anyone can interact with our smart contracts * **Single upfront payment**: you pay once to generate the certification, and it will last forever * **Clear Ownership**: certifications are owned by you, stored inside your wallet * **NFT-based**: implementing ERC-721 standards, each proof is managed through an NFT, containing metadata to better identify the proof, while making easier it's transfer or trade * **Multi-chain**: works on different chains, while keeping a unique ID across them * **Flexible**: files can be kept private, with just the hash being published, or made public via a Chainlink Oracle system # Certify your first file {% hint style="info" %} Currently we're in Testing phase and we support only **Goerli network**. All the below steps can be achieved as long as you have free GoerliETH, that you can require on [Goerli Faucet](https://goerlifaucet.com). {% endhint %} The quickest way to certify your first file, is by using our Web App, that you can access on [app.tproof.io](https://app.tproof.io). The certification process is divided into few simple steps: 1. **Enter the App** and connect your **Ethereum wallet**. You must have a minimum amount of Ethereum to pay for transaction 2. **Select the files** you want to certify. Make sure each file is smaller than 100MB 3. Next to each file, decide if you want to **make it public or not** 4. Click "*Next*" and the procedure starts uploading only the files you decided to make public 5. Optionally, set a **title** to better identify your file. If not provided, the title is a shorter version of the hash. Remember that the more you write, the higher the gas cost will be, as those information are stored on chain (to simplify, you pay a fixed amount of extra gas every 32 chars) 6. You can now review the list of files you're about to upload. Once upload is over, sign and pay the Ethereum transaction That's all! Once the transaction is over, you'll be able to see the NFTs representing the hashes in your personal profile section, or in any NFT Marketplace. {% hint style="info" %} Just publishing the hash is way cheaper than making the file public, as the operations involved are simpler. {% endhint %} ### Public file certification If you have published one or more file, file URL certification requires more time (usually completed in **15-30 minutes**). Once operation is over, and ChainLink nodes confirm the match between File URL and hash, you'll be able to see your file and download it from your personal area, or from any website that shows your NFT's metadata (like OpenSea). # Business and Enterprise At tProof we believe that blockchain is a technology from the future, for the future. As such, it has to be used as much as possible within innovative processes, that embrace everyday challenges. To close the gap between current applications and blockchains, we offer a **Cloud platform**, to simplify the integration of our Smart Contracts. ### Easier integration The first goal of Cloud platform is to **simplify the integration with existing systems**. It is just a light **middleware**, ready to be used, between the customers applications and our blockchain smart contracts. This solution allows anyone to interact with our solution, and leaving us the pain of integrating calls to smart contracts. For a technical point of view, everything works the same, as the core technology is run through the exact same smart contracts you can directly interact with by connecting your wallet inside our dApp. ### UI or API When using the Cloud platform, customers are encourage to use our UI, or to directly integrate with our APIs. To get a sneak peek of the solution, [book a free demo](https://calendly.com/tproof-demo/30min?month=2022-09) to explore it, seeing it live and understanding how the solution works. # Tech introduction Welcome to our more technical section, where we'll describe how the structure of our solution is made. We've decided to make it a Decentralized solution, in a way that anyone can integrate our solution within their project, without any sort of approval on our end. First of all, we go through a **deeper overview** of how information is stored on our solution, and the workflows you should expect. Then, we present the **Smart Contracts** involved in a Proof of Timestamp certification, and how they can be expanded in the future. We'll then present how you can **integrate** it in your project, with a practical example. # 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**. ### 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 `verifyHashFileUrl` function 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. {% hint style="info" %} Being Arweave the only Storage currently supported (you can easily upload files with any Arweave tool, or with the CLI [arkb](https://github.com/textury/arkb)), the information required are: * **Storage Type**: 0 * **URL**: the 43 characters representing a file on Arweave {% endhint %} 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. ### Pay for certification 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_PRICE` public 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. ### Delegation 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 `createProofs` function (aka, minting function) the parameter `_delegateTo`. When minting, a **delegator address can be added**. This delegator will be the only wallet able to call the `verifyHashFileUrl` function 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 `verifyHashFileUrl` function once the file is uploaded on Arweave. In this way, every project can integrate our solution within their protocol, preserving usability and user experience. ### Edit NFT name An NFT name, typically used as **reference to the original file**, can be edited anytime by calling the `editProofTitle` function 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. ### Run an expired or failed verification 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 `extendVerification` function on the Router, paying the `VERIFICATION_PRICE` fee and wait for the certification to complete again. # 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. # Core functions ### Router.sol ```solidity // mint price to register a hash (excluding optional file verification) uint public MINT_PRICE; // ether price to verify a file URL uint public VERIFICATION_PRICE; /** * @notice Generates the tProof for one (or more) given hashes. Each tProof will be in the form of an NFT * @dev All the arrays must have same length and same order: all elements in pos-0 must refer to same hash, etc * @param _hash list of hashes to verify * @param _title list of titles for NFTs. If empty, a shorter version of the hash is used when generating TokenURI * @param _withFileURL true if a public file upload will follow, false otherwise. Prepays the certification call * @param _storageType id of the storage used to store the file. See docs for list. If _withFileUrl is false, this param is ignored (Set it ot 0) * @param _to Who will receive the NFT(s) * @param _delegateTo If we want to delegate another address to call for the verifyHashFileUrl call. Useful for better UX. Set to 0x for empty */ function createProofs( bytes32[] calldata _hash, string[] calldata _title, bool[] calldata _withFileURL, uint16[] calldata _storageType, address _to, address _delegateTo) external payable /** * @notice Allows NFT owner to edit the title of a given NFT * @dev You can pass an array of NFTs, with corresponding titles, to change more titles at the same time * @param _nftNum IDs on NFTs to operate on * @param _title list of titles to assign to NFTs */ function editProofTitle( uint[] calldata _nftNum, string[] calldata _title) external /** * @notice Uploads an URL and triggers the verification of hash connected to the given file * @param _nft List of nft * @param _url list of URLs to verify. See docs to understand the format of it, based on _storageType * @param _storageType The type of storage for each given URL. Needed to verify they match the paid one * @param _mimeType optional mime type for the given file. 0 to set undefined */ function verifyHashFileUrl( uint[] calldata _nft, string[] calldata _url, uint16[] calldata _storageType, uint32[] calldata _mimeType) external /** * @notice Extend the verification period for an hash. Can be used also to verify an hash after a simple mint. If NFT is verified, this function sets it as not verified, thus the verification must re-run again. * @param _nft List of nft * @param _storageType The type of storage for each given NFT where it's plan to upload the file */ function extendVerification( uint[] calldata _nft, uint16[] calldata _storageType) external payable ``` ### HashRegistry.sol ```solidity /** * @notice returns the url connected to a given hash * @param _nft the nft to get the url stored * @param _version the version of the URL to return. See docs based on storageType for the given file. 0 for the essential storage data, 1 for the fullUrl version. Other values may be possible * @return a string representing the url, in the format required **/ function getUrlFromNFT( uint _nft, uint _version) public view returns(string memory) ``` ### NFTFactory.sol ```solidity /** * @notice Update the title of the NFT * @dev Only owner of NFT can update the title of the NFT * @param _nftNum id of NFT to update * @param _title The new title (can also be empty) **/ function updateTitle( uint[] calldata _nftNum, string[] calldata _title) external /** * @notice Set the optional description * @dev Only owner of NFT can update the description of the NFT * @param _nftNum list of NFT to set description * @param _description List of description to associate **/ function setDescription( uint[] calldata _nftNum, string[] calldata _description) external ``` ### **NFTTokenUriGenerator.sol** ```solidity /** * @notice Generates the token URI * @param _tokenId the id of the NFT * @return a string representing the TokenUri **/ function getTokenUri( uint256 _tokenId) external view returns (string memory) ``` ### **HashRegistryStorageType\_ArweaveV1.sol** ```solidity /** * @notice get the string representing the url * @param _nft the nft connected to the url * @param _version the version of the URL to return. See docs based on storageType for the given file. Generally 0 for the essential storage data, 1 for the fullUrl version. Other values may be possible * @return a string representing the url, in the format required **/ function getUrlString( uint _nft, uint _version) external view returns (string memory) ``` # Storage Type The concept of Storage Type has been introduced to make sure our protocol does **not rely only on one storage** but is flexible to accept URLs from different storages. Each storage type is defined by: * **ID** (*uint16*) - a number representing the storage type in our memory * **Name** - an identifier * **ProvidedUrl** (*string*) - the structure of the url that needs to be passed Each StorageType must be compliant with `ItProofHashRegistryStorageTypeInterface.sol`. When retrieving the URL, you can specify a `_version` parameter (*uint256*), that tells the contract how you want back the URL. Typically * **0**: the version sent with ProvidedUrl * **1**: the URL ready to be accessed ## Currently accepted storage types ### Arweave V1 Storage that uses Arweave chain (see ). Each file is identified by a 43 characters string, that is also the identification of the transaction on their chain. **ID:** 0\ **ProvidedUrl**: 43 characters identifying the URL Returned URLs based on `_version` parameter: * **0** - the 43 chars passed as ProvidedUrl * **1** - the full URL in the form of `https://arweave.net/{ProvidedUrl}` # MIME-Types {% hint style="warning" %} Currently we have not yet loaded the MIME-Types on our contracts. Once that feature will be enabled, the MIME-Type list below will be updated. So far the only MIME-Type accepted is "0" (unknown value) {% endhint %} While the official list of MIME-Types can be found [at this link](https://www.iana.org/assignments/media-types/media-types.xhtml), we will initially support just a portion of them, to cover the most used cases. If your MIME-Type is not supported, or it is not available, the value 0 is to represent an unknown MIME-Type. The MIME-Types are stored as *uint32* values, and can be set only if a public file URL has been set. If you want to add a custom MIME-Type that is needed within your project, don't hesitate to contact us! ### Supported MIME-Types ```json { 0: "unknown" } ``` # Integrate with your project As our smart contract are open source, you can feel free to read them, and **integrate directly within your Web3 product**, by integrating the calls to the smart contracts. If you're looking to integrate it within your current **Web 2 or Cloud application**, we highly recommend you to look at our [Business and Enterprise proposal](/business-and-enterprise), as well as [schedule a demo](https://calendly.com/tproof-demo/30min?month=2022-09) with a person of our team. # Supported Networks **Mainnet Network**: * ✔️ **Polygon Mainnet** **Test Network**: * ✔️ **Goerli** * ✔️ **Polygon Mumbai** # Smart Contracts #### Polygon Mainnet (Chain ID 137)
NameAddress
Router​0x4D2efdf4Ef425574CA89279A6700012059884Ae0​
NFTFactory​0xD9184c34d106FfB41F5954484d2273C7c1D03A52​
HashRegistry​0xC0C93106cf7cf32F3bda4eF445646Ccc0FC0C406​
TokenUriGenerator0x04C3Ba18f09964BFFA2ae7Fa9A54A33c2B04267B
HashRegistryStorage - ArweaveV10xbC3d660bBf8bE9400a7f01c09fed4C42AB13D548
UrlVerifierRouter0x5E23A8fdc9D067DE900827c6162AF5C7a883670f
PrivateCollectionAlias0x3d799df30FDEEA6C49d697875174c483D6C40Cc4
NFTFactoryPrivate (isb)0xDc18d153C14E7006bb3298aC2CCceE8f29cCCeB5
### Goerli Testnet (Chain ID 5)
NameAddress
Router0x4A273B48Bd092D79fd925316Bd0A29099097572b
NFTFactory0xd7e3CBE0514eEDc9D989bF033716d4B4CCDA7fd7
HashRegistry0x78A60781f9f77Aa0F970da11E7f19c15c5EEAaB7
TokenUriGenerator0x64E32960e505E0a5F9f051980D5a01E3265D2187
HashRegistryStorage_ArweaveV10xf67500062a7a17FBDA5475AFbA4EA3fC9A6Fe58a
UrlVerifierRouter0xbd3b65C94c9C0901F775F2F1811C5A58C9A3b96a
PrivateCollectionAlias0x8a1d7AEFdfa258EC2ed0D57d7CD4687dEe756e88
NFTFactoryPrivate (sample)0xca9cA2f37c12a397C0E5669E6Efb041C11CD4CC4
NFTTokenUriGeneratorPrivate (sample)0xF823CaDC65f410bFc894B991fA77B4139CFC414c
### Mumbai Testnet (Chain ID 80001)
NameAddress
Router-
NFTFactory-
HashRegistry-
TokenUriGenerator-
HashRegistryStorage_ArweaveV1-
UrlVerifierRouter-
PrivateCollectionAlias0x53b287b360e96280ed0DcA37ABEB997dC29cA55C
NFTFactoryPrivate (sample)0x3fe9bCB557e61b2c437afB9a0E73108Cb7CbdA79
NFTTokenUriGeneratorPrivate (sample)0xa06c414bd53556c1c0ca58275bd0dc83b055de79
# Token and Tokenomics We have a roadmap to **release a Token between Q2 and Q3 of 2023**. The main reasons behind this choice are the following: * prove we can have **real world customers** and use cases before the release of the token * raise fund in a **decentralized way**, by allowing anyone to participate in the protocol * give **real benefits** to token holders * % of the fees generated on chain, directly paid to token holders * DAO participation You can still support us, as we have a currently active [Gitcoin grant page](https://gitcoin.co/grants/7409/tproof). Token will be released in the form of an **NFT collection**, with 10,000 items, each one representing a person. ### Token benefits Two are the main benefits for token holders 1. Earn a **percentage of the fees** generated by the protocol. Every proof requires a fee to be paid, and the token will collect a percentage of those fee across all the chains 2. Participate in the **DAO**. Even if the project won't be directly owned by the DAO, at least in its initial phase, we believe that **token holders participation** can benefit the growth of the project. DAO will have the right to vote in our decisions, to help the team developing a better adopted solution # Team ### MeTony Solidity Developer and blockchain passionate. Make sure to DM me on [Twitter](https://twitter.com/0xMeTony) if you want to discuss Web3-related topics! ### Frenk.eth I'm a Backend developer and Web3 enthusiast. Previously I've been an AWS Architect solution manager. You can [find me on Twitter](https://twitter.com/Frenk_eth) too! # Contact us Quickest way is to send a [DM on Twitter](https://twitter.com/tproofio), and we'll make sure to reply ASAP, or drop us an [email](mailto:team@tproof.io). Feel free also to fill in the following Google form 👇 {% embed url="" %}