# Thallo Two-Way Carbon Bridge - Litepaper ## Abstract Thallo's Two-Way Carbon Bridge allows carbon credits to be moved on and off the blockchain while ensuring transparency and traceability to avoid double accounting and preserving the integrity of the credit. Information about the project, vintage, serial numbers etc are stored on-chain in the Thallo Bridge. This allows anyone to query this data at any time due to the public and distributed nature of the blockchain - even if the registry system is unavailable. The Bridge enables credit retirements to be performed on-chain whilst also being reflected on the underlying registry. As a result the bridge is additive to the existing ecosystem and allows retirees to benefit from the highly credible retirement certificates already being issued by registries, as well as the Proof-of-Retirement NFT for immutable on-chain certification. # Overview

Two-Way Bridge High Level Architecture

The Bridge is made up of two main elements - the API and the Core. The API is a Web2 stack with a HTTPS API to allow integrations to registries, as well as a secure, non-internet facing compute layer for processing sensitive operations. The Bridge Core references the smart contracts that make up the on-chain logic and data. ## Custody Model Thallo uses a custody model to ensure that each and every tokenized credit is backed by exactly one credit of the same project/vintage. We do not employ any over or under collateralization - it is 1:1. This ensures the tokenized credits have the same attributes and market value as their analogue counterparts, whilst still enjoying all the benefits of being fully traceable, transparent and immutable on the blockchain. # Processes There are 3 main processes in the Bridge: * Custody * Retirement * Detokenization ## Custody The registry can trigger a call into the Bridge API when new credits have been custodied by the Thallo custody registry account. As the credits are now fully immobilised and we know they aren't being traded or retired elsewhere we can go ahead and ensure the sending party is known by Thallo and all checks and balances have passed. The Bridge will then write the project and vintage data to the blockchain and mint the tokenized version of these credits. The beneficiary will be the credit sender - usually a project developer but it can be any credit owner. ## Retirement The retirement of credits is triggered on-chain where the event is captured by the Bridge API. The retirement is performed on the underlying registry and the details, such as the serial number of the retired block, is written to a Proof-of-Retirement NFT. The beneficiary of the NFT being the owner of the now retired token. The retirement process is performed in steps and the tokens are not burnt until the off-chain process has completed successfully. This ensures the tokens can be reimbursed to the original owner if there is an issue with the off-chain process. ## Detokenization Token owners are able to claim their underlying credits thanks to our 1:1 collateralization model, if they have a registry account in order to take ownership of the credits. The tokens are held in a programmable escrow before the credits are transferred on the registry. Once complete we burn the escrowed tokenised credits to ensure they are no longer represented on-chain. # Challenges Integrating two systems in a two-way fashion has a lot of nuanced challenges. You have to consider the data structures of both systems, where the trigger points in each system reside, the state machines of the data structures in both systems, and how these state machines operate with one another and which system is the source of truth for data. But the main challenges lie within the security and data integrity between the two systems. Next we'll explore why this is so important. # Handling Financial Assets Thallo's Founding Team has many years experience operating in regulated spaces from energy to finserv. With a solid track record of creating financial systems from ideation in the blockchain space we have applied this experience and expertise throughout the design, implementation and delivery of the Bridge. The Bridge is handling digital assets, backed by real world assets and therefore should be treated with the respect that you would give to any TradFi or DeFi system. The two specific areas are security and data integrity. # API Security The following are a few of the mechanisms and procedures we employ in our Bridge API to keep it secure. ## Segregated Secure Processor All sensitive operations are performed in a secure, non-internet facing compute layer. ## Key Rotation Policy We allow 2 active keys at once so integrators can rotate their keys inline with their corporate policies with zero down time. ## WAF & Monitoring We have proactive monitoring across the infrastructure. A Web Application Firewall helps prevent DDoS attacks and detects common attacks such as SQL injection attempts and brute force attempts. ## Securely Stored Audit Logs Audit logs are stored in a separate, private subnet with no inbound internet access. ## Encryption In Transit and At Rest We use HTTPS (TLS) for encryption in transfit and AES-256 for encryption at rest. ## 3rd Party Security Audit Regular 3rd party security audits are performed against the Bridge. # API Data Integrity Data integrity is incredibly important in any system but is especially true in financial systems. This is made more difficult when the data processing ownership is split across multiple systems. Most of the data itself such as the project and vintage attributes, serial numbers and other underlying data is owned by the registry and that data is the source of truth, therefore it is declared read-only on-chain. However the minting of tokens is a process owned by the Bridge Core and so it is imperative that we mint the correct number of tokens based on the credits we have in the collateralization pool for example. We use a number of techniques to ensure the data is kept in-line. ## Idempotency In essence sending the same request twice is safe and the Bridge won't process it twice. This is a consideration that we've applied across the application and requires a number of checks and balances all the way through the stack. ## Thread Safety The system is horizontally scalable for performance purposes which means it is essentially multi-threaded. Processing the same event at the same time will not ultimately result in it being processed twice. We have taken care across the application to ensure there are no race conditions. In an event driven system like the Bridge, if these are not paid due care and attention there would be several areas that could ultimately cause messages to be processed twice, even with idempotent mechanics in play. ## Safe System Recovery In the case of a system failure the Bridge is able to pick up where it left off and absolutely ensure it doesn't process anything multiple times. This requires careful consideration on the ordering of processes and the ability to re-run processes that have partially completed. # Summary Thallo's two way carbon credit bridge is a suite of smart contracts that enables the issuance (bridging), retirement, and unbridging of Voluntary Carbon Credits (VCCs) in the form of fungible ERC20 tokens. Each token represents a unique project and vintage year combination. The ultimate goal of the bridge is to be a public, transparent ledger of all events related to the issuance and retirement of tokenized carbon credits conducted on Thallo's products. Thallo takes custody of the carbon credits backing the ERC20 tokens on-chain 1:1 on the underlying registry and then issues (mints) them as ERC20 tokens on the blockchain. All events conducted on the underlying registries will be reflected on-chain. The event log for each project and vintage is easily traceable through a single click function called **audit** which displays all issuance, retirement, and detokenization (uncustody) for that project and vintage. The **audit** function returns a trace log of all events that happened on the bridge, as well as information about the current token supply for that project and vintage. When a company or individual user retires carbon credits through Thallo's platform, the retirement is reflected on the underlying registry and then the tokens are burned on-chain. The user is minted a Thallo Proof of Retirement NFT that commemorates this retirement and contains all relevant information about their retirement. ## Process Flows

Smart Contract Process Flows

# Bridge Actions ### Bridge Actions Information for every action taken on the bridge gets stored in the smart contracts and can be retrieved for a specific project and vintage at any time. 1. **Token Issuance** 1. Thallo takes custody of carbon credits on the underlying registry 2. Thallo creates project and vintage on-chain if they do not exist 3. Thallo issues (mints) ERC20 tokens for that specific project and vintage on-chain for the exact amount custodied on the underlying registry 2. **Token Retirement** 1. A user requests to retire their credits on-chain through the TCC.sol smart contract. The tokenized credits are held in escrow in the contract until the retirement is finalized. 2. Carbon credits are retired on the underlying registry and information such as the retirement serial number is created. 3. The retirement is finalized on-chain by a Thallo custodian with the relevant information from the underlying registry. The escrowed tokens are burned. A Proof-of-Retirement NFT is minted to the user commemorating the retirement and containing all relevant information about the retirement. 3. **Detokenization (Uncustody)** 1. A user requests to detokenize their credits on-chain through the TCC.sol smart contract. The tokenized credits are held in escrow until Thallo can confirm the requesting party has an account on the underlying registry that can receive the credits off-chain. 2. Thallo transfers the carbon credits on the underlying registry to the appropriate party and receives relevant information such as block serial numbers. 3. The detokenization is finalized on-chain by a Thallo custodian with all relevant information. The escrowed tokens are burned. # Smart Contract Suite **1. ThalloBridgeRegistry.sol** Smart contract responsible for: * Creating projects on-chain * Creating vintages on-chain. Creating a vintage on-chain means deploying a new Thallo Carbon Credit (TCC) ERC20 contract. #### 2. ThalloBridgeEvents.sol The primary smart contract for interacting with and viewing events that happen on the bridge. * Issues Vintage Tokens. Create ERC20 tokens from underlying carbon credits. * Finalize Retirement. Store information related to carbon credit retirement on-chain and mint a proof of retirement NFT to the user. * Detokenization (Finalize Uncustody). Burn ERC20 credits that have been detokenized and returned to the user on the underlying carbon credit registry. * Audit and view the bridge events logs. Every action taken on the Thallo bridge is stored and can easily be retrieved and viewed with a one click function for each project and vintage. The audit log shows issuance, retirements, and detokenization. The log also contains the information associated with these events such as serial numbers on the underlying registries. The function also confirms that all the data logged matches the current outstanding supply of tokens. $$ TotalSupply = Issuance - Retirement - Detokenization $$ #### 3. TCC.sol Fungible ERC20 smart contract. There is a different contract for each specific project and vintage year combination. The TCC contract contains the logic to: * Request retirement of tokenized carbon credits * Request detokenization of tokenized carbon credits #### 4. ThalloProofOfRetirement.sol Responsible for creating and storing information for Proof-of-Retirement NFTs. Proof-of-Retirement NFTs are created when a user retires carbon credits on Thallo's platform.