A New Generation of Programmable Economy

Intro

Based on the cutting-edge achievements of Web 3.0 technology, GTON Capital is building an infrastructure to advance digital capital markets.

The decentralized digital financial ecosystem has undergone several revolutions in recent years:

• 2009 - Bitcoin The origin of P2P monetary policy and the first digital reserve currency

• 2014 - Ethereum The invention of programmable finance

• 2016 - Maker DAO - DAI The creation of an algorithmic stablecoin protocol and decentralized governance

• 2019 - Rollups A solution to Ethereum's scalability problem

GTON Capital stands on the shoulders of these giants and introduces a new digital currency protocol architecture which is based on the following principles:

• Scaling L1 blockchains with an L2 rollup, where users' assets are stored in revenue-generating vaults and can be redeemed at any time.

• A multi-collateralized stablecoin with a real use case as a native currency for L2.

• Reinvestment of rollup revenue into ecosystem projects and protocol liquidity.

• Distribution of protocol and infrastructure royalties to the community.

• Governance control of protocol capitalization.

Protocol

GTON Capital protocol architecture consists of:

• GTON Network - Community-governed BNB Chain rollup protocol with a multi-collateralized stablecoin as its native currency.

• GTON Dollar - Multi-collateralized stablecoin protocol with a real use case as the native currency for GTON Network rollup.

The three key components of the architecture are represented by smart contracts on the BNB Chain network and a bridge system for BEP20 tokens and for the native rollup token GCD (GTON Dollar). The minting of the native stablecoin token takes place only on the GTON Network, and through a bridge, the stablecoin is made available on the BNB Chain as a BEP20 token.

The original blockchain of the GTON utility token is Ethereum, but the bridge allows it to be transferred to the BNB Chain and the GTON Network. The protocol of the multi-collateral stablecoin GTON Dollar is used only in the GTON Network. In order to mint GCD, it is necessary to bridge tokens available as collateral to the GTON Network and lock them as CDP (collateralized debt position).

Various dApps can be deployed on the rollup, whose users will use GCD to pay transaction fees, the funds from which go to the sequencer and then to the treasury, and are further redistributed in the form of staking rewards for two types of stakers: GTON stakers (currently on the Ethereum network) and GCD stakers (on the GTON Network).

Thus, positions in GTON and GCD allow the user to participate in passive value extraction from any transactional activity on the GTON Network.

Decentralized Oracle Networks (DONs) are used on the rollup to provide applications with the necessary data (prices, events, balances etc).

Technology stack

Economy

The GTON protocol has a dual token model represented by the governance and utility token GTON and the collateralized stablecoin GCD:

The main utility functions of the protocol rely on the GTON utility token and governance functions. The GTON Dollar stablecoin protocol primarily uses stablecoins, but also GTON, ETH and other liquid assets as collateral with different collateralization ratios. Thus, GTON is not only a governance token of the GTON Dollar protocol (i.e. a functional analog of the DUCK token in the Unit protocol), but is also used as collateral in it. Globally, the revenues of the GTON protocol are distributed to the holders of both tokens in the proportion determined by the governance decisions of the GTON holders.

GTON issuance is capped at 21 million tokens and is deflationary, similar to BTC. Although there is an allocation for staking in the protocol, it is limited and only allows the issuance to be used initially as an additional incentive to join the protocol. In the long run, all staking rewards will be taken from the funds generated by users of the rollup and applications on it.

Rollup is monetized via dApp activity and GTON Network infrastructure.

Use Cases

Let's take a look at the basic use cases for the GTON network, without going into detail about the variety of applications built on top of it by third-party development teams. Consider two basic cases, the only difference being that Alice is free to use any allowed security.

I. Alice believes in the potential of the protocol and wants to use applications on the GTON network. However, she only owns BNB on Binance and does not want to sell it. Therefore, Alice bridges BNB to the GTON network and uses it as collateral to issue some GCD stablecoins. Since the stablecoin is the native token of the protocol, Alice can immediately transfer any tokens and use a variety of dApps: exchanges, lending protocols, NFT marketplace or farming services. When Alice does not need GCD to pay for transactions, she can use it for stablecoin staking to generate profit that is redistributed by the other users of the GTON network. After some time, Alice notices that her BNB has increased significantly in value. However, Alice only needs the amount of GCD she borrowed in the beginning to close the debt position. As a result, Alice ends up in a "triple win" situation: she kept her BNB, generated value from applications, and also received profit from commissions from protocol users.

Suppose in this example that Alice does not own BNB, but GTON. In this case, Alice can simply stake the token and reap rewards from the activity on the GTON network, or she can bridge it into the chain and use it as collateral, just like in case I. As we can see, cases 1 and 2 complement each other, so Alice can stake any tokens allowed by the GTON dollar governance from her portfolio as collateral, but at the same time effectively use GCD to profit from the rollup activity.

Vision

As a foundation, GTON Capital creates capital efficient technologies and products by synergizing the best elements of Web 3.0.

GTON's ultimate goal is to empower millions of users to invent and explore new experiences in decentralized digital capital markets. Business models, community structures, and collaborative creativity are being stitched together and redefined by GTON Capital to create a more sustainable, equitable, and efficient future for the global economy.

GTON Network is currently a BNB Chain Layer 2 Rollup blockchain with the stablecoin $GCD as its native currency.

GTON Network is a fork of Optimism, whereas $GCD is a fork of Unit Protocol. By forking and combining these protocols together, GTON Network is building an unprecedentedly powerful rollup-based ecosystem with the primary goal of becoming a haven for GameFi, SocialFi and Real World Assets (RWA) apps and services. The strategic priority of the ecosystem is those products and services that directly attract live users and convert them into community and DAO members. In addition, GTON Network supports all basic DeFi primitives: DEXes, Multisigs, Farming, Lending, and NFT protocols.

Intro

The surge of the number of Ethereum transactions in the past few years led to more and more expensive fees. The GTON Network has its roots in L2 blockchains called Optimistic Rollups: their primary goal is to increase the throughput and reduce the cost of executing transactions. The GTON Network inherits from the Optimism L2 a fault-proof method of "rolling up" transactions and sending them in batches to Ethereum, leveraging its security. Moreover, in GTON Network, the low blockchain fees are being paid in $GCD, a multicollateralized stablecoin.

This chapter explains the architecture of GTON Network and emphasizes its features that allow it to provide low latency, low gas fees, and high throughput, which are necessary to ensure the best user experience for the users of GameFi & SocialFi dApps.

An optimistic Ethereum rollup relies on the security and the consensus mechanism of the "parent" blockchain for fraud protection. Several actors, such as sequencers, proposals, and verifiers, take part in the process to confirm the legitimacy of transactions generated by the rollup users. Another name for rollups is L2 – Layer 2.

In 2022, GameFi was a large trend, but it has not reached its potential mainly because of the excessive predominance of games with mechanics and game-based economy models akin to the “musical chairs" game or the excessive minting of reward tokens for participating in certain activities in games. However, a new wave of interest in this sector is expected. There will be other game mechanics and other forms of project monetization and the “earning” aspect for users.

The GTON has started active work in three areas:

• Co-developing a learn2earn blockchain game that will be announced at the beginning of Q4 and will launch tentatively in November.

• Planning to give away small grants to teams of third party game developers, in particular games based on prediction markets, one of which will be introduced immediately after the mainnet release.

• Launching the “partnership machine” to attract successful games from Ethereum, Polygon and BSC to release their versions on GTON Rollup.

SocialFi is the market of DAOs and NFT communities. In this area, the GTON team is developing a NFT marketplace and basic infrastructure in the form of a DEX and a Multisig protocol, as well as cooperating with DAO tooling developers.

RWA (Real World Assets) is an interesting trend that has occurred in recent years in the cryptocurrency and web3 industry. It is worth noting that it was USDT, USDC or BUSD that made a key contribution to the fact that millions of people can now use the popular blockchain networks. The application of the RWA concept resulted in the revolution of fiat stablecoins, which now hold much of the capital and transaction volumes. The new wave will involve tokenized commodities: gold and other metals, food crops, oil and other tangible assets such as cars or residential real estate. These are assets that have real utility and rarity, being connected to the global economy, and therefore will always have value that differs from the purely speculative one, in contrast with most crypto assets. Ultimately, web3 can automate and optimize the global economy and create global services for all kinds of assets and transactions. RWA is not limited to tokenization of goods, but can also facilitate implementing web3 mechanics for services that already form the basis of the IT economy: rental markets, B2B franchises, product marketplaces and ads. Through NFTs, users can tokenize goods, commercial and residential rentals and real estate itself, rental cars, scooters or computers: all huge markets in which web3 technology could lead a new revolution, as web1 and web2 did in the recent past.

Focusing on GameFi, SocialFi, and Real World Assets gives us the opportunity to grow from the bottom up, creating services and products that work with real people, not bots. It is the focus on users that determines the success in capitalization growth, community building, and brand awareness.

Merkle Tree Transaction Batch Root (MTTBR) is an ordered list of transactions.

Merkle Tree State Root (MTSR) is a calculated state hash of the transaction execution.

GTON Network Smart Contract L2 infrastructure contains several process loops that prevent possible malfunctions of decentralized actors and unintended behavior of external malicious actors.

Below, the main process of transaction execution in GTON Network is described.

The User, the actor that sends the transactions, submits a transaction to the Block Producer, the actor responsible for propagating the blocks through the Peer Network. The Block Producer forms the blocks for the L2 Smart Contracts and propagates them through the Peer Network.

The User gets confirmation of the transaction from the L2.

Then, the Sequencer, responsible for providing transaction data and the data batch to other entities from the L2, receives the full transaction data from the Peer Network and computes the data batch: Merkle Tree Transaction Batch Root (MTTBR) and Merkle Tree State Root (MTSR).

The Sequencer submits the full transaction data to Memolabs that stores the transaction data off-chain, from where it will be provided to the Verifier, the counterpart of a Sequencer, responsible to verify that sequencer does not provide false/invalid data.

At regular intervals, the Sequencer submits the batch of data to Layer 1 (MTTBR and MTSR), the set of smart contracts on Ethereum that handle the security of the system and solve the disputes between Sequencer and Verifier.

The Verifier attempts to download the full transaction data from Memolabs or the Peer Network by retrieving the MTTBR on Layer 1 that was submitted by the Sequencer. It computes its own MTTBR from the full transaction data it received from Memolabs / Peer Network.

Then, the Verifier downloads the Sequencer’s MTTBR and MTSR from Layer 1. It compares its own roots with the roots submitted to Layer 1 by the Sequencer.

If the Verifier’s MTTBR corresponds to Sequencer’s MTTBR, the Verifier computes its own MTSR, downloads the Sequencer’s MTSR from Layer 1 submitted by the Sequencer, and compares its own calculated MTSR with the Sequencer’s MTSR.

If the Verifier’s MTSR is equal to Sequencer’s MTSR, the transactions and state are valid.

Fraud Prevention

If the Verifier’s MTSR is not equal to Sequencer’s MTSR, the Verifier submits the transaction data it received from the Memolabs or the Peer Network to Layer 1 and marks them challengeable;

The Verifier can submit a Fraud Proof. The Fraud proofing process will proceed just as a regular Optimistic Rollup hereafter.

If the Verifier’s MTTBR is not equal to Sequencer’s MTTBR, then the Verifier requests the Sequencer via fee payment to post the Sequencer’s transaction data on Layer 1. This fee payment is collected on Layer 1 as an upfront amount to pay for the request fees. The fees are sent to the Governance Protocol, responsible for anything related to the efficiency of the system, to pay for potential reimbursements caused due to griefing. The Sequencer will have a time window (in # of blocks, currently set at around 24 hours) to respond and is responsible for the resulting gas fee. Both the Sequencer and Verifier lose money in this process. The System enters the insecure transaction state for the data availability request time window until the next rotation. During this time the Verifier requests the Sequencer to provide valid transaction batch data.

GTON Capital: reimagining the utility and scalability of Web3

GTON Capital is building an ecosystem of blockchain products whose combined features will make Web 3.0 more sustainable and value-driven.

The GTON Capital team is building an ecosystem of innovative Web 3.0 infrastructure and products by bringing together the best achievements of decentralized web technologies.

Vision

The vision of the GTON team is a new phase in the evolution of the cryptocurrency landscape, with decentralized stablecoins and scalable smart contract execution layers at its core, enabling millions of dApps to improve the experience of billions of users.

We are currently facing a "Cambrian explosion" of alt-L1 and L2 protocols, DeFi dApps and NFTs, GameFi and X2Earn business models, and metaverses. Despite the fact that it all started as brand new decentralized currencies powered by PoW consensus, such as BTC-Bitcoin and ETH-Ethereum, these currencies cannot be adopted as means of payment for Web3 users because of their price volatility. This is why stablecoins pegged to the world's major reserve currencies and assets have changed the game and accelerated the adoption of Web3. We see the same issue with ETH being used as a transaction currency after the hundredfold price spike. Ethereum has become even more expensive for users because of network congestion. This problem needs to be solved to facilitate adoption and it is now being addressed by so-called rollups.

This is where GTON Capital plays its strategic role in reimagining the utility and scalability of Web3 by creating a Rollup protocol with a decentralized stablecoin as the gas currency.

Goal

GTON Capital's ultimate goal is to empower millions of users to invent and explore new experiences in decentralized digital capital markets. GTON Capital connects and redefines business models, community structures and collaborative creativity in an effort to create a more sustainable, equitable and efficient future for the global economy.

GTON Protocol is set to become the technological foundation for a cutting-age, diverse ecosystem for more sustainable and engaging financial, gaming, social and other types of applications.

Protocol

GTON Protocol represented by three main components:

Stablecoin

• GTON Capital Dollar is a multicollateralized stablecoin protocol with a real use case for use as the native currency for the GTON Network rollup.

• GCD is a stablecoin that is algorithmically soft-pegged to the US dollar via smart contracts. It uses tokens from another decentralized cryptocurrency as collateral to issue new GCDs. ETH, BTC, PAXG and other liquid currencies can be used as collateral. The design principles are similar to DAI, GHO, MIM, sUSD, LUSD, USDP and other crypto-collateralized stablecoins.

Rollup

• GTON Network is an Optimistic Rollup protocol on top of BNB Chain that uses the GCD stablecoin as its gas currency.

• GTONNet is an EVM-compatible network that supports the execution of smart contracts written for BNB Chain, Ethereum and other EVM-based networks. All other tools for users and developers are also integrated into GTONNet, such as MetaMask wallet, HardHat and bridges. Users get the same experience as with Arbitrum, Optimism, Metis and Boba, the major difference being that they do not need to use volatile assets for transactions, but can use the GCD stablecoin instead.

Staking

• GTON Staking is a tool for protocol contributors that allows them to capture the value from the ecosystem of products built on GCD and GTONNet.

Infinite scalability of the Rollups and GTON protocol

Although GTONNet is a L2 on top of BNB Chain mainnet, the rollup technology can be scaled recursively to L3/4 and other layers. This means that businesses can run their own permissioned L3s on top of the Rollup, or dApps can run L3s to scale the user base if they need more network capacity.

This is how the decentralized stablecoin and the scalable smart contract execution layer from GTON Capital it’s playing its strategic role for Web3 to enable millions of dApps such as DeFi, Games or CyberSport to make the lives of billions of users happier.

Strategy

The operational goals of GTON Labs, the development company behind GTON Protocol open software, as well as the overall GTON Ecosystem’s end goal, is to enable growth in the use of the GTON Stablecoin (GCD) and the L2 blockchain (GTON Network). To do so, users will be given a unique experience in playing web3 games, trading NFTs and gaining value from DeFi services, with security derived from BNB Chain.

About GTON Capital

GTON Capital builds infrastructure to advance digital capital markets including GTON Network — L2 BNB Chain rollup with $GCD stablecoin as a native currency, Pathway — algorithms for the pricing of governance tokens, set of mutually reinforcing DeFi protocols, DONs, and more.

By combining cutting-edge achievements of Web 3.0 technology, GTON Capital creates a more advanced and stable foundation for DeFi development.

GCD Stablecoin needs to be minted and moved from Layer 1 to Layer 2. So, moving GCD from L1 to L2 is necessary. The easiest way to move some GCD tokens from L1 to L2 is the GCD Bridge.

The GCD bridge is made up of two primary contracts:

• Layer 1: L1CrossDomainMessenger

• Layer 2: L2CrossDomainMessenger

Sending GCD Tokens from L1 to L2

• Step 1: Lock GCD tokens on the L1CrossDomainMessenger contract.

• Step 2: The L1CrossDomainMessenger contract will send a message to the L2CrossDomainMessenger contract, and L2CrossDomainMessenger will notice it.

• Step 3: The L2CrossDomainMessenger will mint some GCD equal to the amount of GCD that was deposited on Layer 1.

Withdrawing GCD Tokens from L2 to L1

• Step 1: Send a withdrawal request to the L2CrossDomainMessenger contract on Layer 2.

• Step 2: The L2CrossDomainMessenger contract will burn an equal amount of GCD that you have requested for withdrawal and send a message to the L1CrossDomainMessenger contract to unlock the equal amount of GCD.

• Step 3: Wait for a couple of days for the result of the fraud-proof process.

• Step 4: At the end, send a second withdrawal transaction to the L2CrossDomainMessenger contract to get the funds.

All Contracts

The GTON Network L2 system contains an L1/L2 bridge system with the following contracts:

• CrossDomainEnabled.sol - a helper contract that enables cross-domain communications.

• ICrossDomainMessenger.sol - an interface for cross-messenger contracts.

• IL1ERC20Bridge.sol - an interface for L1 ERC20 bridge.

• IL1StandardBridge.sol - an interface for L1 bridge.

• IL2ERC20Bridge.sol - an interface for L2 ERC20 bridge.

• IL2StandardERC20.sol - an interface for L2 bridge.

• L1ChugSplashProxy.sol - a contract with proxy implementation functionality.

• L1StandardBridge.sol - the L1 bridge with functionality for depositing ETH, depositing ERC20 tokens, finalizing ETH and ERC20 withdrawal.

• L2StandardBridge.sol - the L2 bridge with functionality for withdrawing ETH and finalizing deposit.

• Lib_AddressManager.sol - a library for setting and getting the address and name hash.

• Lib_AddressResolver.sol - a library that resolves the address associated with a given name.

• Lib_PredeployAddresses.sol - constant predeploy addresses.

• OVM_GasPriceOracle.sol - a gas price oracle with functionality to update fees, gas price, ERC20 bridging parameters.

• iL1ChugSplashDeployer.sol - an interface for the proxy contract.

• iMVM_DiscountOracle.sol - an interface for the discount oracle.

• iOVM_SequencerFeeVault.sol - a contract holding fees paid to the Sequencer.

Privileged roles

• The owner can pause contracts, set the gas price, change the minimum L1 gas limit, and transfer fees to an address.

• onlyFromCrossDomainAccount is a role used to finalize deposits, ETH or ERC20 withdrawals, and finalize chain switching and chain configuration.

Sequencer

The sequencer is a single, semi-privileged party that plays a critical role in rollup systems, specifically in the process of generating transactions. The sequencer is started by the creator of the system and there is only one sequencer at a time within the system.

It can be hosted in a cloud or as a consensus blockchain node. Its primary responsibility is to check the validity of transactions. When a user of the rollup needs to perform a transaction, it is the role of the sequencer to confirm it, update the state, construct L2 blocks and submit to L1.

The presence of a sequencer in an optimistic Ethereum blockchain is mandatory; it is responsible for assigning order to L2 transactions, similar to L1 miners.

The sequencer determines the ordering of transactions in the CanonicalTransactionChain. To do so, the sequencer must process transactions instantly, without delay. This process must follow the constraints imposed by appendSequencerBatch(). Also, the sequencer must add transactions from the CTC queue during the so-called "Force On Period".

The sequencer flow is thus:

• The sequencer receives new transactions from blockchain users.

• It must check, without delay, that the transactions are valid, sort them, and apply them to the local state as a pending block.

• It periodically submits them to the CanonicalTransactionChain contract.

• As a result, a confirmation message is sent to the user, resulting in an orderly execution of L2 transactions. For the end user, this process takes about a few seconds and indicates that the transaction will be included in the next rollup batch. This gives instant confirmation, therefore it has weaker security compared to L1 transactions. But compared to 0-conf L1 transactions, the security is higher. If the batch of sequencer transactions is confirmed at L1, the security level remains the same.

If the sequencer is unavailable or has become malicious, L2 users can directly post transactions to the CanonicalTransactionChain contract.

Resistance to censorship

In the event that a malicious sequencer censors the user's transactions, the user can enqueue() transactions directly into the L1 queue. This will force the sequencer to include transactions in the L2 queue within the FORCE_INCLUSION_PERIOD transaction. If any transaction in the queue is older than FORCE_INCLUSION_PERIOD blocks, that transaction must be added to the chain before the protocol allows the sequencer to add other transactions. If the sequencer stops sending transactions completely, the protocol allows users to add transactions to the CTC by calling appendQueueBatch().

Therefore, even if the sequencer is actively censoring a user, the user can always continue to send transactions on the network.

Fault proofs

In any Optimistic Rollups, state commitments are published to Ethereum without any direct proof of their validity. Instead, there is a "challenge window" to ensure that the commitment proofs are valid. At first, all commitments are considered pending for a certain period of time. If nobody challenges the commitment during the challenge window, it becomes final. If a commitment is challenged, it is considered invalidated through a “fault proof” process and is removed from the StateCommitmentChain.

The sequencer periodically posts transactions to the CanonicalTransactionChain contract, where all Optimistic Rollup blocks are stored. At the next stage, the sequencer reads the batch of the user-published transactions in the CanonicalTransactionChain contract to process them and produce a State Batch. Then, it appends the generated Merkle root: it is an important part of the process as verifiers (other smart contracts) can use Merkle tree proofs it to verify the validity of the batch that occurred recently.

Proposers & Verifiers

Note that the proposer role is expected to change in the future, but currently it works identically to the sequencer.

These two roles are necessary to evaluate and commit transactions. The evaluation happens in the Canonical Transaction Chain, and then the resulting state is committed by writing it to the State Commit Chain. Proposers must pay a bond to obtain privilege for this role.

Verifiers perform the same functions as proposers, but some differences must be considered. A verifier evaluates transactions in the Canonical Transaction Chain to determine the resulting state root after each transaction.

If the verifier detects an incorrect proposed state root, it will be considered a case of fraud. As a result, a reward is earned, which is deducted from the proposed state root. In such a verification model, multiple accounts can contribute to the fraud protection process and increase the overall security of the process. In this way, these accounts can earn rewards.

Verifiers read transactions from the Canonical Transaction Chain. They process transactions and verify that the state roots in the state commit chain are correct. If the state root is invalid, the verifier initiates and completes a fraud-proof task. There is a convenient cross-chain communication contract L1CrossDomainMessenger , which can verify these proofs on behalf of other contracts.

There are three fees that users need to pay to borrow GCD tokens:

• Stability fee: paid when a user deposits collateral to borrow GCD tokens. The price is stable and does not fluctuate during the borrowing period once set.

• Liquidation fee: calculated as the percentage of the loan which the borrower has to pay if liquidation is triggered. If this happens, the liquidation fee is deducted from the collateral that the user used to open the position.

• Pool fee: a stable 3% fee that is deducted from the conversion of assets and USD values in the oracle contract

The smart contract system in GTON Network is inherited from Optimism and Metis. Below are the key parts that support the logic of the Layer 2 platform.

Layer 1

L1 is composed of different kinds of contracts, primarily used to facilitate messaging from L1 to L2 and ensure a correct ordering of transactions:

• Messaging Contracts that support message exchange from L1 to L2.

  • L1 Cross Domain Messenger

    The role of the L1 Cross Domain Messenger contract is to send messages from L1 to L2. It also relays messages from L2 to L1 and is responsible for keeping rejected messages that are passing from L1 to L2. Please note: if a message sent from L1 to L2 is rejected, it can be resubmitted via the replay function of this contract.

  • L1 Standard Bridge

    The L1 Standard Bridge contract is used for storing locked L1 funds that users intend to bridge from L1 to L2 and are already locked on the L2. The contract synchronizes with a corresponding L2 bridge to get information about deposits and newly finalized withdrawals.

• Rollup Contracts on L1 (Ethereum mainnet) that store ordered lists of transactions and of commitments to the L2 state roots.

  • L1 Rollup Contracts

    • They store an ordered list of all transactions that are submitted to the L2 state, such as:

      • The proposed state root that results from the application of each transaction.

      • Transactions sent from L1 to L2 that are pending in the ordered list.

  • Canonical Transaction Chain CTC (append only) Defines the ordering of transactions by writing them to the Chain Storage Container (CSC). Allows any account to ‘enqueue’ L2 transactions that the sequencer will eventually append to the state.

  • State Commitment Chain SCC

    Contains a list of proposed state roots.

  • Chain Storage Container CSC Gives reusable storage and provides its owner contract with read, write, and delete functionality.

• Verification

  Verification on L1 is necessary to prove the integrity of the proposed state roots that come from each transaction. If the state root is deemed correct, the verifier will receive a reward. If not, the verifier can initiate a transaction challenge.

Layer 2

• Messaging

  Contracts that support message exchange from L2 to L1.

  • Layer 2 Cross Domain Messenger Sends messages from L2 to L1.

  • L2 Standard Bridge

    The L2 Standard Bridge works together with the L1 Standard Bridge to enable the transfer of GCD between L1 and L2. It mints new tokens on L2 deposited into the L1 Standard Bridge, or burns the withdrawn tokens and informs their unlock on L1.

• Predeploys

  Can be found at addresses with 0x42 prefixes. They handle common operations.

  • OVM_DeployerWhitelist

    It is owned by the GTON team and helps with mainnet rollout by allowing whitelisted addresses to do ovmCREATE or ovmCREATE2 operations.

  • OVM_ETH

    The OVM ETH predeploy provides an ERC20 interface for GCD deposited to L2. Unlike L1, L2 accounts do not have a balance field.

  • OVM_GasPriceOracle

    This contract determines the current L2 gas price. The gas fee depends on network congestion.

  • OVM_L2ToL1MessagePasser

    A utility contract that facilitates an proof of a L1 message on L2. This proof is performed in its _verifyStorageProof function. As a result, it verifies the existence of the transaction hash in the ‘sendMessages’ mapping of the L2ToL1MessagePasser contract.

  • OVM_SequencerFeeVault

    Used for fees paid to the sequencer.

Contracts

• CDPManager01.sol— a contract that contains functions that allow the users to deposit collaterals and borrow GCD tokens, or repay GCD to close their debt positions. It is responsible for calling functions in the Vault.sol contract to manage collateralized debt positions.

• CDPRegistry.sol — a contract that dynamically stores data about collateral addresses and their owners' addresses. It contains functions used to verify, add or remove owners' addresses from the Collateralized Debt Position (CDP) data based on to user activity.

• CollateralRegistry.sol — a contract that allows you to add or remove a collateral token address.

• GCD.sol - a simple ERC20 token contract. Total supply is not capped, and additional minting is allowed. Vault contract address can mint new tokens or burn users’ tokens without allowance. It has the following attributes:

  • Name: GCDStablecoin

  • Symbol: GCD

  • Decimals: 18

• OracleRegistry.sol — a contract that manages oracles, allowing to set or unset oracles and oracle types for assets.

• Vault.sol — is the core contract that holds and manages the collateral for all debt positions. It controls the minting or burning of GCD stablecoin according to borrowing or repayment transactions.

• VaultParameters.sol — an upgradable contract that allows for the management of the GCD system. It establishes the fundamental parameters for the project, such as allowed collaterals, oracle types, stability fees, liquidation fees, vault access, and foundations.

• LiquidationAuction02.sol— a contract that allows to burn GCD tokens and take the calculated amount from collateral tokens from liquidated positions. The redeem function can be called by anyone, but it is reserved for the system manager.

• ChainlinkedOracleMainAsset.sol— the oracle contract that gets USD prices for given tokens.

• VaultManagerParameters.sol — management contract that allows the manager to set borrowing and liquidation fees.

• ReentrancyGuard.sol — a contract module that helps prevent reentrant calls to a function.

• TransferHelper.sol — a simple contract that contains safe transfer and safe approve functions for the given ERC20 token addresses and values.

• ForceTransferAssetStore.sol — a contract that maps assets to a boolean status of forcing a single token transfer.

• UniswapV3Oracle.sol — a contract to get USD value of GCD tokens. During this conversion, the default pool fee is 3%, which is stable.

• TickMath.sol— a math library for computing sqrt prices for ticks of size 1.0001.

• FullMath.sol — enables division and multiplication with no loss of precision when an intermediate value is overflown.

• OracleLibrary.sol — a library contract that provides functions to integrate with V3 pool oracle.

• PoolAddress.sol — a contract that provides functionality for deriving a pool address from the factory, tokens, and fee.

• LowGasSafeMath.sol — a library contract that provides optimized overflow and underflow safe math operations.

Privileged roles

• The manager role can:

  • add/remove an asset address to be used as collateral

  • set stability and liquidation fees, oracle type and token debt limit

  • mark asset as `shouldForceTransfer`

  • set/unset oracle addresses and their oracle types

  • set quote params in UniswapV3Oracle

  • set default TWAP period

  • set default quote aasset

• The vault role can:

  • mint/burn GCD tokens

  • create new debt positions, deposit collaterals, borrow GCD tokens, withdraw collaterals, repay debt and update users’ debt

Money Markets

Conventionally, money markets were centralized structures facilitating the deals between lenders and borrowers.

• Borrowers approach money markets to get a short-term loan.

• If the borrowers can’t pay back their loans, the lenders can sell the collateral to recover the loaned funds (liquidate).

• When the loan is repaid, the collateral is returned.

• Borrowers are required to pay interest to the lenders and a fee to the money market.

#CeFi or #CeDeFi

Below is an example of how centralized finance (CeFi) lending works. The same model is used for so-called Centralized DeFi, where cryptocurrency is introduced into the picture but is used in a centralized manner.

A borrower borrows a $100 USDT using BTC as collateral. Since BTC is a volatile asset, there needs to be a certain overcollateralization to have an ability to liquidate and secure the lender. After a certain period, the borrower can use the borrowed asset for leverage trading, farming etc. In the end, the borrower has to return a larger amount of Tether to receive the collateral back.

Decentralized Money Markets

• Powered by blockchain technology and run by a smart contract

• Immutable

• Decentralised

• Permissionless

• Non-custodial

• Composability

• Overcollateralized

#DeFi

In DeFi, a similar principle is used. Most often the currencies are different, instead of BTC, ETH is used as collateral. Examples of such projects are Compound and Aave.

Decentralized stablecoin minting

A similar protocol can be used not only to lend and borrow a stablecoin, but also to mint it. MakerDAO and DAI is an example of such protocol. A CDP (a collateral debt position) is being entered by a borrower to mint and use the stablecoin.

GCD works similarly: ETH & GTON can be used by borrowers to mint it and later use it on the rollup as the native token.

GTON Dollar (GCD) is a multi-collateralized stablecoin protocol with a real use case as a native currency for GTON Network rollup. As a lending platform, it accepts different ERC20 tokens as collateral to borrow liquidity as GCD tokens. System mints GCD tokens when a debt position is created and burns GCD tokens when a debt position is closed. Staking of GCD tokens yields a sustainable APR.

GCD is a decentralized stablecoin whose value is soft pegged to the US dollar, which means that GCD attempts to maintain a value of $1 USD. GTON Money protocol used for minting GCD is a fork of Unit Protocol. GCD is multi-collateralized, which means that it's fully-backed by collateral in the form of different third-party cryptoassets.

A key component of the architecture is a bridge system for ERC20 tokens and for GCD. The minting of the native stablecoin token occurs only in the GTON Network, and through the MNTR bridge, the stablecoin is made available on the Ethereum network as an ERC20 token.

The original blockchain of the GTON utility token is Ethereum, but the standard ERC20 bridge allows it to be transferred to the GTON Network. The protocol of the multi-collateral stablecoin GTON Dollar is deployed only in GTON Network. In order to mint GCD, it is necessary to bridge ERC20 tokens available as collateral to the GTON Network and lock them as CDP (collateralized debt position).

Different dApps can be deployed on the rollup, whose users will use GCD to pay transaction fees, the funds from which go to the sequencer and then to treasury and are further redistributed in the form of staking rewards for two types of stakers: GTON stakers (on the Ethereum network) and GCD stakers (on GTON Network).

Thus, positions in GTON and GCD allow the user to participate in passive value extraction from any transactional activity on the GTON Network.

All circulating GCDs are generated within the system that allows a user to mint it. The user can lock any amount of the asset, which the protocol accepts as collateral and borrow the GCD stablecoin in return. As a result, the user will obtain some amount of liquidity in order to use that liquidity as an additional income tool without selling their asset.

The repayment of the debt and collateral withdrawal can be performed at any time after a debt position has been opened. GCD is destroyed when loans are paid back.

GCD is used as the native currency on the GTON Network.

Due to a reorganization within our engineering team and a recent surge in support ticket activity, we have decided to extend the deadline for the Tokenswap & Liquidation program by one month. The new deadline is now set for July 15, 2023. For any inquiries, please create a support ticket on Discord.

Given the feedback provided by GTON holders, we have decided to offer the options of either exchanging GTON for the OGXT token on our rollup, or for stablecoins that are currently held in the treasury.

At the time of the liquidity withdrawal, the final trading price for GTON was 22 cents per token. We have added a bonus to this price and will set the swap rate at 32 cents per GTON held, meaning that regardless of which option you choose, you will receive the same dollar value equivalent at the time of the swap.

OGXT swap

If you choose to receive OGXT, as per the original proposal, then:

• For every 1 GTON, you will receive 4.76 OGXT, based on the 21:100 ratio of the respective token supplies (21 million for GTON and 100 million for OGXT).

• OGXT distribution will begin on April 15th, 2023, at 17:00 Dubai time (GMT+4).

• The token swap will end on July 15th, 2023, at 17:00 Dubai time (GMT+4). Please make sure to send your GTON tokens to the team's Safe address by this deadline. Instructions are provided below.

Initially, the tokens will be non-tradable, and we will provide OGXT/GCD liquidity at a later date. When the process is over, the initial trading price will be approximately 0.06722 GCD per OGXT, resulting in a dollar value of 32 cents per GTON held.

As we are launching on a new infrastructure, please note that the options for token transfers to other blockchains can be limited in the beginning. Here are the limitations we foresee:

• We are developing a reverse bridging service but it’s not yet publicly available. This means that until the bridging service is up and running, you will temporarily not be able to bridge your OGXT/GCD to BNB Chain.

• As of this moment, GCD is currently not directly tradable on BNB Chain and will remain illiquid for some time. However, we are collaborating with the Wombat exchange (and others) to establish a new stable pool for the token. GCD is an over-collateralized token, so it is unlikely to lose its USD peg, and the minter (most likely the treasury) can redeem the underlying collateral for these tokens.

• Reintegration of OGXT to LBank will require additional work: we aim to modify the listing and swap GTON for OGXT on the exchange and are currently in negotiation with the LBank team on how to proceed.

Technical instructions for the swap

1. We only accept GTON tokens. If you own sGTON (staked GTON), it must be unstaked, and GTON must be received back. Please use the terminal interface to unstake your sGTON, with the command >unstake all. If you encounter any problems, use the command >help.

Stablecoin swap

We will make a separate announcement through standard channels with more details about the process, ensuring everyone is prepared to make a choice by the given deadline.

In response to the question regarding the initial OGXT/GCD ratio being set at 0.32, please note the following.

Token holders are presented with two alternatives:

• The option to execute a GTON to OGXT token swap at a ratio of 21/100, effectively receiving approximately 4.76 OGXT for each GTON. This arrangement was approved in the project's latest DAO proposal.

• For those who wish to convert their GTON positions into liquid stablecoins, the team has offered a ratio of 1 GTON to 0.32 USD stablecoin (USDT, USDC, BUSD), which exceeds the price on decentralized exchanges (DEXes). This alternative serves as a replacement for the discontinued LP management following the community accepting the token swap proposal. The proposed OGXT/GCD ratio after the token swap is based on the final GTON price of $0.22 as determined by the market prior to the withdrawal of DEX liquidity, with an additional bonus built in. The bonus is the 0.10 GCD premium in genesis valuation for each OGXT token.

It is critical to recognize that the price of the token is subject to the unpredictable forces of the open market. Historical data shows that the price has fluctuated above and below the entry level for extended periods of time. In an open market, it remains the prerogative of each token holder to hold or dispose of tokens as they see fit. However, the project team would like to thank all backers who have remained steadfast in their support despite the opportunity to sell. The backers continue to strive to develop the ecosystem with the goal of optimizing the utility and usage of OGXT.

Nevertheless, for those seeking immediate liquidity, the option to exchange tokens at the last market determined price is available in addition to the above bonus value. This alternative is also available to those who are unable to proceed with Option 1 due to regulatory restrictions applicable to residents, citizens and corporations of the United States, as stated in the Legal Disclaimer of the GTON Capital project.

LiquidationAuction02

vault

contract IVault vault

vaultManagerParameters

contract IVaultManagerParameters vaultManagerParameters

cdpRegistry

contract ICDPRegistry cdpRegistry

forceTransferAssetStore

contract IForceTransferAssetStore forceTransferAssetStore

DENOMINATOR_1E2

uint256 DENOMINATOR_1E2

WRAPPED_TO_UNDERLYING_ORACLE_TYPE

uint256 WRAPPED_TO_UNDERLYING_ORACLE_TYPE

Buyout

event Buyout(address asset, address owner, address buyer, uint256 amount, uint256 price, uint256 penalty)

Trigger when buyouts are happened

checkpoint

modifier checkpoint(address asset, address owner)

constructor

constructor(address _vaultManagerParameters, address _cdpRegistry, address _forceTransferAssetStore) public

buyout

function buyout(address asset, address owner) public

Buyouts a position's collateral

_liquidate

function _liquidate(address asset, address user, uint256 collateralToBuyer, uint256 collateralToOwner, uint256 repayment, uint256 penalty) private

_calcLiquidationParams

function _calcLiquidationParams(uint256 depreciationPeriod, uint256 blocksPast, uint256 startingPrice, uint256 debtWithPenalty, uint256 collateralInPosition) internal pure returns (uint256 collateralToBuyer, uint256 collateralToOwner, uint256 price)

CDPRegistry

CDP

struct CDP {
  address asset;
  address owner;
}

cdpList

mapping(address => address[]) cdpList

cdpIndex

mapping(address => mapping(address => uint256)) cdpIndex

vault

contract IVault vault

cr

contract ICollateralRegistry cr

Added

event Added(address asset, address owner)

Removed

event Removed(address asset, address owner)

constructor

constructor(address _vault, address _collateralRegistry) public

checkpoint

function checkpoint(address asset, address owner) public

batchCheckpointForAsset

function batchCheckpointForAsset(address asset, address[] owners) external

batchCheckpoint

function batchCheckpoint(address[] assets, address[] owners) external

isAlive

function isAlive(address asset, address owner) public view returns (bool)

isListed

function isListed(address asset, address owner) public view returns (bool)

_removeCdp

function _removeCdp(address asset, address owner) internal

_addCdp

function _addCdp(address asset, address owner) internal

getCdpsByCollateral

function getCdpsByCollateral(address asset) external view returns (struct CDPRegistry.CDP[] cdps)

getCdpsByOwner

function getCdpsByOwner(address owner) external view returns (struct CDPRegistry.CDP[] r)

getAllCdps

function getAllCdps() external view returns (struct CDPRegistry.CDP[] r)

getCdpsCount

function getCdpsCount() public view returns (uint256 totalCdpCount)

getCdpsCountForCollateral

function getCdpsCountForCollateral(address asset) public view returns (uint256)

CollateralRegistry

CollateralAdded

event CollateralAdded(address asset)

CollateralRemoved

event CollateralRemoved(address asset)

collateralId

mapping(address => uint256) collateralId

collateralList

address[] collateralList

constructor

constructor(address _vaultParameters, address[] assets) public

addCollateral

function addCollateral(address asset) public

removeCollateral

function removeCollateral(address asset) public

isCollateral

function isCollateral(address asset) public view returns (bool)

collaterals

function collaterals() external view returns (address[])

collateralsCount

function collateralsCount() external view returns (uint256)

GCD

ERC20 token

name

string name

symbol

string symbol

version

string version

decimals

uint8 decimals

totalSupply

uint256 totalSupply

balanceOf

mapping(address => uint256) balanceOf

allowance

mapping(address => mapping(address => uint256)) allowance

Approval

event Approval(address owner, address spender, uint256 value)

Trigger on any successful call to approve(address spender, uint amount)

Transfer

event Transfer(address from, address to, uint256 value)

Trigger when tokens are transferred, including zero value transfers

initialize

function initialize(address _parameters) public

_authorizeUpgrade

function _authorizeUpgrade(address) internal

Restricted upgrades function

mint

function mint(address to, uint256 amount) external

Only Vault can mint GCD

Mints 'amount' of tokens to address 'to', and MUST fire the Transfer event

burn

function burn(uint256 amount) external

Only manager can burn tokens from manager's balance

Burns 'amount' of tokens, and MUST fire the Transfer event

burn

function burn(address from, uint256 amount) external

Only Vault can burn tokens from any balance

Burns 'amount' of tokens from 'from' address, and MUST fire the Transfer event

transfer

function transfer(address to, uint256 amount) external returns (bool)

_Transfers 'amount' of tokens to address 'to', and MUST fire the Transfer event. The function SHOULD throw if the from account balance does not have enough tokens to spend.

transferFrom

function transferFrom(address from, address to, uint256 amount) public returns (bool)

Transfers 'amount' of tokens from address 'from' to address 'to', and MUST fire the Transfer event

approve

function approve(address spender, uint256 amount) external returns (bool)

Allows 'spender' to withdraw from your account multiple times, up to the 'amount' amount. If this function is called again it overwrites the current allowance with 'amount'.

increaseAllowance

function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool)

_Atomically increases the allowance granted to spender by the caller.

This is an alternative to approve that can be used as a mitigation for problems described in IERC20.approve.

Emits an Approval event indicating the updated allowance.

Requirements:

• spender cannot be the zero address._

decreaseAllowance

function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool)

_Atomically decreases the allowance granted to spender by the caller.

This is an alternative to approve that can be used as a mitigation for problems described in IERC20.approve.

Emits an Approval event indicating the updated allowance.

Requirements:

• spender cannot be the zero address.

• spender must have allowance for the caller of at least subtractedValue._

_approve

function _approve(address owner, address spender, uint256 amount) internal virtual

_burn

function _burn(address from, uint256 amount) internal virtual

CDPManager01

vault

contract IVault vault

vaultManagerParameters

contract IVaultManagerParameters vaultManagerParameters

oracleRegistry

contract IOracleRegistry oracleRegistry

cdpRegistry

contract ICDPRegistry cdpRegistry

WETH

address payable WETH

Q112

uint256 Q112

DENOMINATOR_1E5

uint256 DENOMINATOR_1E5

Join

event Join(address asset, address owner, uint256 main, uint256 gcd)

Trigger when joins are happened

Exit

event Exit(address asset, address owner, uint256 main, uint256 gcd)

Trigger when exits are happened

LiquidationTriggered

event LiquidationTriggered(address asset, address owner)

Trigger when liquidations are initiated

checkpoint

modifier checkpoint(address asset, address owner)

constructor

constructor(address _vaultManagerParameters, address _oracleRegistry, address _cdpRegistry) public

receive

receive() external payable

join

function join(address asset, uint256 assetAmount, uint256 gcdAmount) public

Depositing tokens must be pre-approved to Vault address position actually considered as spawned only when debt > 0

Deposits collateral and/or borrows GCD

join_Eth

function join_Eth(uint256 gcdAmount) external payable

Deposits ETH and/or borrows GCD

exit

function exit(address asset, uint256 assetAmount, uint256 gcdAmount) public returns (uint256)

Tx sender must have a sufficient GCD balance to pay the debt

Withdraws collateral and repays specified amount of debt

exit_targetRepayment

function exit_targetRepayment(address asset, uint256 assetAmount, uint256 repayment) external returns (uint256)

Repayment is the sum of the principal and interest

Withdraws collateral and repays specified amount of debt

exit_Eth

function exit_Eth(uint256 ethAmount, uint256 gcdAmount) public returns (uint256)

Withdraws WETH and converts to ETH

exit_Eth_targetRepayment

function exit_Eth_targetRepayment(uint256 ethAmount, uint256 repayment) external returns (uint256)

Repayment is the sum of the principal and interest

Withdraws WETH and converts to ETH

_repay

function _repay(address asset, address owner, uint256 gcdAmount) internal

_ensurePositionCollateralization

function _ensurePositionCollateralization(address asset, address owner) internal view

triggerLiquidation

function triggerLiquidation(address asset, address owner) external

Triggers liquidation of a position

getCollateralUsdValue_q112

function getCollateralUsdValue_q112(address asset, address owner) public view returns (uint256)

_isLiquidatablePosition

function _isLiquidatablePosition(address asset, address owner, uint256 usdValue_q112) internal view returns (bool)

Determines whether a position is liquidatable

_ensureOracle

function _ensureOracle(address asset) internal view

isLiquidatablePosition

function isLiquidatablePosition(address asset, address owner) public view returns (bool)

Determines whether a position is liquidatable

utilizationRatio

function utilizationRatio(address asset, address owner) public view returns (uint256)

Calculates current utilization ratio

liquidationPrice_q112

function liquidationPrice_q112(address asset, address owner) external view returns (uint256)

Calculates liquidation price

_calcPrincipal

function _calcPrincipal(address asset, address owner, uint256 repayment) internal view returns (uint256)

VaultManagerParameters

initialCollateralRatio

mapping(address => uint256) initialCollateralRatio

liquidationRatio

mapping(address => uint256) liquidationRatio

liquidationDiscount

mapping(address => uint256) liquidationDiscount

devaluationPeriod

mapping(address => uint256) devaluationPeriod

constructor

constructor(address _vaultParameters) public

setCollateral

function setCollateral(address asset, uint256 stabilityFeeValue, uint256 liquidationFeeValue, uint256 initialCollateralRatioValue, uint256 liquidationRatioValue, uint256 liquidationDiscountValue, uint256 devaluationPeriodValue, uint256 gcdLimit, uint256[] oracles) external

Only manager is able to call this function

Sets ability to use token as the main collateral

setInitialCollateralRatio

function setInitialCollateralRatio(address asset, uint256 newValue) public

Only manager is able to call this function

Sets the initial collateral ratio

setLiquidationRatio

function setLiquidationRatio(address asset, uint256 newValue) public

Only manager is able to call this function

Sets the liquidation ratio

setLiquidationDiscount

function setLiquidationDiscount(address asset, uint256 newValue) public

Only manager is able to call this function

Sets the liquidation discount

setDevaluationPeriod

function setDevaluationPeriod(address asset, uint256 newValue) public

Only manager is able to call this function

Sets the devaluation period of collateral after liquidation

Vault

Vault is the core of GCD Protocol GCD Stablecoin system

Vault stores and manages collateral funds of all positions and counts debts

Only Vault can manage supply of GCD token

Vault will not be changed/upgraded after initial deployment for the current stablecoin version

weth

address payable weth

DENOMINATOR_1E5

uint256 DENOMINATOR_1E5

DENOMINATOR_1E2

uint256 DENOMINATOR_1E2

gcd

address gcd

collaterals

mapping(address => mapping(address => uint256)) collaterals

debts

mapping(address => mapping(address => uint256)) debts

liquidationBlock

mapping(address => mapping(address => uint256)) liquidationBlock

liquidationPrice

mapping(address => mapping(address => uint256)) liquidationPrice

tokenDebts

mapping(address => uint256) tokenDebts

stabilityFee

mapping(address => mapping(address => uint256)) stabilityFee

liquidationFee

mapping(address => mapping(address => uint256)) liquidationFee

oracleType

mapping(address => mapping(address => uint256)) oracleType

lastUpdate

mapping(address => mapping(address => uint256)) lastUpdate

notLiquidating

modifier notLiquidating(address asset, address user)

initialize

function initialize(address _parameters, address _gcd, address payable _weth) public

_authorizeUpgrade

function _authorizeUpgrade(address) internal

Restricted upgrades function

receive

receive() external payable

update

function update(address asset, address user) public

Updates parameters of the position to the current ones

spawn

function spawn(address asset, address user, uint256 _oracleType) external

Creates new position for user

destroy

function destroy(address asset, address user) public

Clears unused storage variables

depositMain

function depositMain(address asset, address user, uint256 amount) external

Tokens must be pre-approved

Adds main collateral to a position

depositEth

function depositEth(address user) external payable

Converts ETH to WETH and adds main collateral to a position

withdrawMain

function withdrawMain(address asset, address user, uint256 amount) external

Withdraws main collateral from a position

withdrawEth

function withdrawEth(address payable user, uint256 amount) external

Withdraws WETH collateral from a position converting WETH to ETH

borrow

function borrow(address asset, address user, uint256 amount) external returns (uint256)

Increases position's debt and mints GCD token

repay

function repay(address asset, address user, uint256 amount) external returns (uint256)

Decreases position's debt and burns GCD token

chargeFee

function chargeFee(address asset, address user, uint256 amount) external

Transfers fee to foundation

triggerLiquidation

function triggerLiquidation(address asset, address positionOwner, uint256 initialPrice) external

Deletes position and transfers collateral to liquidation system

liquidate

function liquidate(address asset, address positionOwner, uint256 mainAssetToLiquidator, uint256 mainAssetToPositionOwner, uint256 repayment, uint256 penalty, address liquidator) external

Internal liquidation process

changeOracleType

function changeOracleType(address asset, address user, uint256 newOracleType) external

Only manager can call this function

Changes broken oracle type to the correct one

getTotalDebt

function getTotalDebt(address asset, address user) public view returns (uint256)

Calculates the total amount of position's debt based on elapsed time

calculateFee

function calculateFee(address asset, address user, uint256 amount) public view returns (uint256)

Calculates the amount of fee based on elapsed time and repayment amount

VaultParameters

stabilityFee

mapping(address => uint256) stabilityFee

liquidationFee

mapping(address => uint256) liquidationFee

tokenDebtLimit

mapping(address => uint256) tokenDebtLimit

canModifyVault

mapping(address => bool) canModifyVault

isManager

mapping(address => bool) isManager

isOracleTypeEnabled

mapping(uint256 => mapping(address => bool)) isOracleTypeEnabled

vault

address payable vault

foundation

address foundation

initialize

function initialize(address payable _vault, address _foundation) public

The address for an Ethereum contract is deterministically computed from the address of its creator (sender) and how many transactions the creator has sent (nonce). The sender and nonce are RLP encoded and then hashed with Keccak-256. Therefore, the Vault address can be pre-computed and passed as an argument before deployment.

_authorizeUpgrade

function _authorizeUpgrade(address) internal

Restricted upgrades function

setManager

function setManager(address who, bool permit) external

Only manager is able to call this function

Grants and revokes manager's status of any address

setFoundation

function setFoundation(address newFoundation) external

Only manager is able to call this function

Sets the foundation address

setCollateral

function setCollateral(address asset, uint256 stabilityFeeValue, uint256 liquidationFeeValue, uint256 gcdLimit, uint256[] oracles) external

Only manager is able to call this function

Sets ability to use token as the main collateral

setVaultAccess

function setVaultAccess(address who, bool permit) external

Only manager is able to call this function

Sets a permission for an address to modify the Vault

setStabilityFee

function setStabilityFee(address asset, uint256 newValue) public

Only manager is able to call this function

Sets the percentage of the year stability fee for a particular collateral

setLiquidationFee

function setLiquidationFee(address asset, uint256 newValue) public

Only manager is able to call this function

Sets the percentage of the liquidation fee for a particular collateral

setOracleType

function setOracleType(uint256 _type, address asset, bool enabled) public

Only manager is able to call this function

Enables/disables oracle types

setTokenDebtLimit

function setTokenDebtLimit(address asset, uint256 limit) public

Only manager is able to call this function

Sets GCD limit for a specific collateral

GTON Network allows you to use your favorite tools to develop and deploy contracts. Below is an example of how to add the testnet GTON Network to your Hardhat config file:

module.exports = {
  networks: {
    ...
    // for testnet
    'gton-testnet': {
      url: "https://testnet.gton.network/",
      chainId: 50021,
      accounts: [privateKey1, privateKey2, ...]
    },
  },
  ...
}

You can ask for assistance in GTON Capital’s Discord server, #support channel, our team members respond most quickly there.

Oracles connect blockchains to external systems and provide smart contracts with external information. A GTON Oracle gives Ethereum projects on-time data from the outside world to perform reliable actions on the L2.

GTON Network hostes a dedicated Blockscout instance to provide blockchain explorer services.

Please use this guide to learn how to verify your deployed contracts:

OGX (Original) GTON Exchange

The use-cases served by the DEX are long and short trading of synthetic assets, which will use an implementation of the Pathway protocol, a launchpad for new projects in the ecosystem, plus a special tokenomic mechanics where profit for LP providers is distributed not as the farming rewards, but through the buy-back & burn mechanism of the main Relay Token.

OGXT Relay Token

The previous tokenomics of the legacy GTON token would not allow for such mechanics to be implemented because the supply of the token is limited to 21 mln tokens, and there was no possibility of minting more of it in the future.

The GTON Labs team is conducting a token swap of GTON to OGXT to implement an ABR-APR tokenomics in it:

• 0.3% trading fees conversion to OGXT and burn

• Staking APR 10%

• 100 mln total supply during initial token release (4.761 OGXT for 1 GTON)

• Max supply limited by ABR-APR ratio

• Same proportional token distribution as GTON

The utility of the OGXT token is inherited from the utility of the GTON token:

• Governance of OGX and all related products and services

• Collateral for GTON Dollar

• Fixed APR staking

• Relay token

• Value capture via Annual Burning Rate (burning fees)

That is, in fact, the same token with improved tokenomics for a native value capture and a focus on a real use-case as a Relay token in the token ecosystem.

OG Exchange Token Use Cases

Summing up, the list of use-cases for the exchange token is:

• Mirrored assets

• Integrated launchpad

• Leverage trading (derivatives)

• Multichain support

• Cross-chain swap

1. Type help to see all available commands

2. Type join to connect MetaMask wallet

3. To mint & bridge GCD to GTON Network use command bridge <amount> <token> For example bridge 10 busd would mint 9 GCD (collaterization ratio - 90%, liquidation price for BUSD is around $0.95 - which is unlikely to happen. At any time you can redeem your tokens returning 9 GCD and getting back the 10 BUSD collateral). Works with BUSD and USDC collateral on BNB Chain

If you need to do the same manually:

Testnet - Goerli

Explorer

Faucet If you'd like to try testing the network, you can receive GCD on BSC by contacting the team on Discord or Telegram.

Method: depositERC20ToByChainId

Parameters:

0.0002 - Ether value

50021 - Chain ID

0x213ecae6b3cbc0ad976f7d82626546d5b63a71cb - L1 token

0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000 - L2 token

20000000000000000000 - 20 GCD

0 - L2 gas

0x00 - Data

The funds will arrive within 5 minutes.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~$137 602 ($0.137 mln) POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3.152 mln POA

Total GTON: 17,37 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$58,252 POA

Total GTON: ~1.033 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$471,694 POA

Total GTON: ~0.151 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$1,292 POA

Total GTON: ~0.034 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$25,759 POA

Total GTON: ~0.131 mln

Summary

According to the April report, the Treasury accounts own $0.137mln of #POL and $3.709mln of #POA.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~$39787 ($0.039 mln) POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3.156 mln POA

Total GTON: 17,37 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$401,906 POA

Total GTON: ~1.055 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$36,714 POA

Total GTON: ~0.927 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$650 POA

Total GTON: ~0.034 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$37,098 POA

Total GTON: ~0.135 mln

Summary

According to the May report, the Treasury accounts own $0.039mln of #POL and $3.632mln of #POA.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

Total: ~$327 000 (0.327 mln) POL (GTON LPs)

Funds (#POA)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3.157 mln POA

Total GTON: 17.37 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$545 592 POA

Total GTON: 1.033 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: $223 357 POA

GTON: 0.035 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: $15 407 POA

GTON: 0.034 mln

Bscscan BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: $9 476 POA

GTON: 0.323 mln

As of January 15, 2024, nearly 50% of OGXT holders have agreed to liquidate their positions. If you are an OGXT holder and wish to liquidate your position into stablecoins (0.1344 USDC per 1 OGXT), please follow these instructions:

1. 1. Sign in to BSChat with the account where your OGXT is held:
2. 2. Send any message (like "Hi," "Hello," or your question) to the GTON Communication Team Account (ogxt.eth):
3. Read about the reasons behind the decision to stop development and the options offered: (1) liquidate your position into stablecoins, or (2) waive option (1) and request a role in the newly formed charitable organization (Foundation) focused on social entrepreneurship and education.

The development of the project has been paused for an undefined period.

All OGXT token holders have two options to choose from, available

Until March 31, 2024, at 6:00 PM CET.

Please be aware that the estimated response time can range from a few hours during working days to a few days. We may not provide responses on weekends and public holidays.

We look forward to communicating with you in BSChat!

Also, if you missed the OGXT swap campaign, you still have the opportunity to liquidate your GTON position under the previous terms.

More about the “GTON -> OGXT Swap” Campaign:

Project Update:

Development paused. Due to a bear market, our platform has seen minimal user activity. Key contributors, including developers and partners, have left, impacting the industry. Our shift to AI and Blockchain didn't resonate, with poor user engagement. Following the UST-Terra-LUNA crisis, stablecoins faced regulatory issues, clashing with our stablecoin transaction model. Legal challenges in setting up international operations have arisen. While the newly formed Foundation remains operational, with ongoing education and ecosystem projects, we're halting development due to the lack of users and regulatory compliance. Thus, all token, NFT, and liquidity operations are indefinitely on hold.

Strategy

A so-called "Beta 15" strategy that determines an optimal structure of DAO LP treasuries is proposed here. In a nutshell, this strategy means keeping 15% of market volatility risk for GTON and 85% in stablecoin LPs. Below the reasoning behind the strategy is explained in relation to the current market sentiment circa January 2022.

Finance math foundations

The regression formula calculates the return on asset valuation:

where alpha is the factor of the internal (independent) return on the asset and its economic characteristics and performance,

Rm is the portfolio return that represents the market,

beta is market sensitivity factor,

zeta is noise.

Treasury diversification

DAOs should be tasked with evaluating beta parameters and designing funds management strategies to optimize and control the beta factor for its governance token in accordance with the project's goals and long-term vision.

Considering so-called DeFi 2.0 DAOs who manage POL (protocol owned liquidity) on different DEXes and CEXes, we can say that the majority of such funds/liquidity positions are related to LP (MM liquidity) tokens with the governance token in the pair. This means that the GovToken performance depends on the performance of quote assets within LPs.

To limit the beta factor to a certain range, DAOs have to diversify their LP positions proportionally between stablecoins, project tokens and volatile assets. Some DAOs planned to have more than one token as part of their tokenomics: these sets of tokens are considered as alpha factors and should not be limited.

In an extreme case where Rm becomes negative (market correction), the implementation of beta-15 means that this correction will only have 15% negative influence on the DAO token performance.

Practical implementation

Parameters like alpha, beta, and the noise are determined empirically which means that to be useful they must be measured on historical asset price performance. However, if there is no trading history yet or the project is changing its token economy model, we assume that it is safe to start with an initial LP diversification with 85% in stablecoin LPs and 15% in volatile asset LPs.

After some time, an empirical beta coefficient can be estimated and the LP treasury can be rebalanced to decrease or increase stablecoin LP allocation to bring future beta coefficient close to the target value (such as 15%).

Beta-15 example

The approach explained above has a target beta of 15 and it can be initiated as "85/15 = stablecoins/tokens" treasury diversification. The time period for this structure can be 4 weeks.

Why not beta-0

Beta-0 means that all GovToken liquidity is represented by stablecoin/GovToken LPs. This approach makes sense if there is no goal to use Governance token for trading utility. Therefore, no arbitrage opportunities or any other organic MM activity around governance tokens in that case will exist, or it will be severely limited. In addition, limiting beta by a certain X means that the managers of DAO liquidity will be keeping beta lower than X, meaning that for certain time periods beta can temporarily be close to 0.

In accordance with the 2022 GC Roadmap proposal adopted by the DAO participants, we are starting the practice of monthly Treasury balance reports. In each report we will compare balances and their dynamics of change in dollar terms. Changes in balances occur due to changes in asset prices, the activity of traders and arbitrageurs, as well as development spending, operational expenses, market making, and marketing activities. Snapshots will be taken on the 19th of each month and reports will be published on the 21st.

Treasury Snapshot Reports

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~$ 365743 ($0.365 mln) POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3,158mln POA

Total GTON: 17,36 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$12.7 POA

Total GTON: ~0.029 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$31612 POA

Total GTON: ~0.471 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$ 7791 POA

Total GTON: ~0.055 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$2139 POA

Total GTON: ~0.147 mln

Summary

According to the July report, the Treasury accounts own $0,365mln of #POL and $3,199mln of #POA.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~$157 000 ($0.157 mln) POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3.154 mln POA

Total GTON: 17,37 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$416,679 POA

Total GTON: ~1.033 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$93,368 POA

GTON: ~0.109 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$15,316 POA

GTON: ~0.034 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$94,192 POA

GTON: ~0.322 mln

Summary

According to the March report, the Treasury accounts own $0.157mln of #POL and $3.774mln of #POA.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~$449503 ($0.449 mln) POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3.164mln POA

Total GTON: 17,37 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$1137,14 POA

Total GTON: ~0.000912 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$22125 POA

Total GTON: ~0.442 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$3579 POA

Total GTON: ~0.049 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$2576 POA

Total GTON: ~0.147 mln

Summary

According to the June report, the Treasury accounts own $0.449mln of #POL and $3.194mln of #POA.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~$202455.646 ($0.203 mln) POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$2,859 mln POA

Total GTON: 16,86 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$200609 POA

Total GTON: ~0.584 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$30607 POA

Total GTON: ~0.471 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$7631 POA

Total GTON: ~0.055 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$79455.32 POA

Total GTON: ~0.147 mln

Summary

According to the August report, the Treasury accounts own $0,203mln of #POL and $3,177mln of #POA.

Intro

In accordance with the 2022 GC Roadmap proposal adopted by the DAO participants, we are starting the practice of monthly Treasury balance reports. In each subsequent report we will compare balances and their dynamics of change in dollar terms (this report has no such section since it is the first of its kind). For example, the February report will be interpreted in the context of changes that have happened since January, and so forth.

Almost all assets (#POA - protocol owned assets) are stored on so-called multisig accounts, and the totality of multisig accounts in various blockchain networks is considered the GC Treasury.

Liquidity in the form of LP tokens is also stored in the Treasury. Almost all liquidity belongs to the Treasury and is therefore classified as #POL (protocol owned liquidity).

(!) The figures presented in the report cannot be 100% accurate due to market volatility, ongoing development and market-making operations. In addition, in some cases the data is rounded up to 1 thousand in dollar terms for convenience of representation.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values: ~22k$ divided by 0.02 (corresponding to 2%).

Total: ~$1.1mln POL (GTON LPs).

Funds (#POA)

Funds are all crypto assets owned by the protocol which aren't GTON or GCEco tokens. We operate the following accounts managed by smart contract multisigs with different consensus policies.

Main GC Treasury

Policy: 6 out of 10 signatures, with supervision (signatures) of external advisors.

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$3.154mln POA

Total GTON: 17.37 mln GTON

ETHNet Ops Treasury

Policy: 4 out of 6 signatures, managed by GC core contributors.

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$0.552mln POA

Total GTON: 1.033 mln GTON

FTMNet Ops Treasury

Policy: 4 from 6 signatures, managed by GC core contributors.

(this screenshot did not include ZOO in the amount of 478k at a price of $0.031 = $15k).

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$0.43mln POA

Total GTON: 0.022mln GTON

MATICNet Ops Treasury

Policy: 4 from 6 signatures, managed by GC core contributors.

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$3.5k POA

Total GTON: 0.00mln GTON

BSCNet Ops Treasury

Policy: 4 from 6 signatures, managed by GC core contributors.

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~10k$ POA

Total GTON: 0.320mln GTON

Summary

According to the January report, the Treasury accounts own $1.1mln of #POL (that is, $0.55 mln in assets and $0.55mln in GTON at the current rate, mainly FTM and Fantom blue chips), as well as $4.151mln (mostly stablecoins) of #POA.

In total, the balance of Treasury assets excluding GTON is around $4.7mln.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~ 104 261 ( 0,104 ml) $POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ≈ 2.560mln

Total GTON: ~ 16,57 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ≈ 2.105 $ POA

Total GTON: ~ 0,876 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ≈ 22 122 $POA

Total GTON: ~ 0,559 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ≈ 379 $POA

Total GTON: ~ 0,054 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ≈ 4 934 $POA

Total GTON: ~0,147mln

Summary

According to the October report, the Treasury accounts own $0,104 mln of #POL and ~$2,8 mln of #POA

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~ 114 453 ( 0,114 ml) $POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ~$2 608 064 POA = 2.608mln

Total GTON: ~ 16,57 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ~$64 525 POA

Total GTON: ~ 0,875mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ~$24 874 POA

Total GTON: ~0,559 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ~$12 250 POA

Total GTON: ~ 0,055 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ~$23 811 POA

Total GTON: ~0,148 mln

Off-chain Ops Balance:

*cash, bank balance, security, CeFi, CeDeFi, CEX and other deposits and assets (RWA) which can't be stored on-chain.

Total: ~0.15 mln$

Summary

According to the September report, the Treasury accounts own $0.114mln of #POL and $~2,9mln of #POA

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~ 75 433.75 ( 0,0754 ml) $POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ≈ 2.273 844mln

Total GTON: ~ 16,57 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ≈ 30 034 $ POA

Total GTON: ~ 0,816 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ≈ 17 801 $POA

Total GTON: ~0,554 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ≈ 6 986 $POA

Total GTON: ~ 0,055 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ≈ 14 295 $POA

Total GTON: ~0,148 mln

Off-chain Ops Balance:

*cash, bank balance, security, CeFi, CeDeFi, CEX and other deposits and assets (RWA) which can't be stored on-chain.

Total: ~0.235 mln$

Summary

According to the October report, the Treasury accounts own $0,0754 mln of #POL and ~$2,578 mln of #POA

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~ 1677.25 (0,0016 ml) $POL

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ≈ 1 794 840 $ POA

Total GTON ≈ 16,57 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ≈ 28 952.65 $ POA

Total GTON ≈ 0,734 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ≈ 48 724.57 $ POA

Total GTON: ≈ 0,585 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ≈ 9 461.57$ POA

Total GTON: ≈ 0,055 mln

BSCNet Ops Treasury

Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a

Total: ≈ 15 185.98 $ POA

Total GTON: ≈ 0,148 mln

Off-chain Ops Balance:

*cash, bank balance, security, CeFi, CeDeFi, CEX and other deposits and assets (RWA) which can't be stored on-chain.

Total: ~0.416,57 mln$

Summary

According to the March report, the Treasury accounts own $0,0016 mln of #POL and $2,314 mln of #POA.

GTON Liquidity (#POL)

The total liquidity on AMM DEXes can be calculated as the sum of all “+2% Depth” values divided by 0.02 (corresponding to 2%).

~ 69273.93 (0,0672 ml) $POL (GTON LPs)

Main GC Treasury

Address: 0x953555e0af401bd031a5a53c72efa81fae464276

Total: ≈ 2 196 166 mln

Total GTON: ~ 16,57 mln

ETHNet Ops Treasury

Address: 0xbE70EB523398464De569A84F447576f4f169D8d9

Total: ≈ 30 035 $ POA

Total GTON: ~ 0,723 mln

FTMNet Ops Treasury

Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a

Total: ≈ 104 847 $POA

Total GTON: ~0,572 mln

MATICNet Ops Treasury

Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807

Total: ≈ 6 907 $POA

Total GTON: ~ 0,055 mln

BSCNet Ops Treasury