# GTON Capital ⚜️ Explained
Please note that this documentation is a work in progress and will be updated frequently.
## 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.
[**Website**](https://gton.capital/) **|** [**Twitter**](https://twitter.com/GtonCapital) **|** [**Discord**](https://discord.com/invite/Ce972zqGW6) **|** [**GitHub**](https://github.com/GTON-capital) **|** [**Youtube**](https://www.youtube.com/channel/UC_bq0AoqZHaBhYsw3sMIlGw) **|** [**Mirror**](https://mirror.xyz/0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0) **|** [**Blog**](https://www.blog.gton.capital/)
# Brief Intro
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.
# GTON Capital in Detail
Please note that this documentation is a work in progress and will be updated frequently.
> ## **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
Rollup infrastructure based on [**Optimistic**](https://community.optimism.io/docs/developers/)
Multi-collateral CDP Stablecoin based on [**Unit Protocol**](https://unit.xyz)
Custom Oracles based on [**Chainlink DON**](https://docs.chain.link/docs/running-a-chainlink-node/) standards
Cross-chain messaging based on [**LayerZero**](https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf) and Optimistic
## 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.
# GameFi, SocialFi, & Real World Assets
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.
# GTON Network
### 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.
# Basics of Rollups
### 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.
# Protocol Overview
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.
# L2 Processes
**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, t*he transactions and state are valid.
### Fraud Prevention
*If the Verifier’s MTSR is not equal to Sequencer’s MTSR, t*he 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.
# Bridge
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.
# GTON Dollar (GCD)
**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.
The complete list of the currently available collaterals can be found and GCD can be minted through [GTON CLI](https://cli.gton.capital/).
GCD is used as the native currency on the GTON Network.
**Token Symbol:** GCD\
**Decimals:** 18\
**Token Address Ethereum:**
# Lending, CDP, and Money Markets
### 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.
# Fees
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
# GCD Contracts
### 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
# Solidity API
## LiquidationAuction02
#### vault
```solidity
contract IVault vault
```
#### vaultManagerParameters
```solidity
contract IVaultManagerParameters vaultManagerParameters
```
#### cdpRegistry
```solidity
contract ICDPRegistry cdpRegistry
```
#### forceTransferAssetStore
```solidity
contract IForceTransferAssetStore forceTransferAssetStore
```
#### DENOMINATOR\_1E2
```solidity
uint256 DENOMINATOR_1E2
```
#### WRAPPED\_TO\_UNDERLYING\_ORACLE\_TYPE
```solidity
uint256 WRAPPED_TO_UNDERLYING_ORACLE_TYPE
```
#### Buyout
```solidity
event Buyout(address asset, address owner, address buyer, uint256 amount, uint256 price, uint256 penalty)
```
*Trigger when buyouts are happened*
#### checkpoint
```solidity
modifier checkpoint(address asset, address owner)
```
#### constructor
```solidity
constructor(address _vaultManagerParameters, address _cdpRegistry, address _forceTransferAssetStore) public
```
| Name | Type | Description |
| ------------------------- | ------- | --------------------------------------------------------- |
| \_vaultManagerParameters | address | The address of the contract with Vault manager parameters |
| \_cdpRegistry | address | The address of the CDP registry |
| \_forceTransferAssetStore | address | The address of the ForceTransferAssetStore |
#### buyout
```solidity
function buyout(address asset, address owner) public
```
*Buyouts a position's collateral*
| Name | Type | Description |
| ----- | ------- | ------------------------------------------------------ |
| asset | address | The address of the main collateral token of a position |
| owner | address | The owner of a position |
#### \_liquidate
```solidity
function _liquidate(address asset, address user, uint256 collateralToBuyer, uint256 collateralToOwner, uint256 repayment, uint256 penalty) private
```
#### \_calcLiquidationParams
```solidity
function _calcLiquidationParams(uint256 depreciationPeriod, uint256 blocksPast, uint256 startingPrice, uint256 debtWithPenalty, uint256 collateralInPosition) internal pure returns (uint256 collateralToBuyer, uint256 collateralToOwner, uint256 price)
```
## CDPRegistry
#### CDP
```solidity
struct CDP {
address asset;
address owner;
}
```
#### cdpList
```solidity
mapping(address => address[]) cdpList
```
#### cdpIndex
```solidity
mapping(address => mapping(address => uint256)) cdpIndex
```
#### vault
```solidity
contract IVault vault
```
#### cr
```solidity
contract ICollateralRegistry cr
```
#### Added
```solidity
event Added(address asset, address owner)
```
#### Removed
```solidity
event Removed(address asset, address owner)
```
#### constructor
```solidity
constructor(address _vault, address _collateralRegistry) public
```
#### checkpoint
```solidity
function checkpoint(address asset, address owner) public
```
#### batchCheckpointForAsset
```solidity
function batchCheckpointForAsset(address asset, address[] owners) external
```
#### batchCheckpoint
```solidity
function batchCheckpoint(address[] assets, address[] owners) external
```
#### isAlive
```solidity
function isAlive(address asset, address owner) public view returns (bool)
```
#### isListed
```solidity
function isListed(address asset, address owner) public view returns (bool)
```
#### \_removeCdp
```solidity
function _removeCdp(address asset, address owner) internal
```
#### \_addCdp
```solidity
function _addCdp(address asset, address owner) internal
```
#### getCdpsByCollateral
```solidity
function getCdpsByCollateral(address asset) external view returns (struct CDPRegistry.CDP[] cdps)
```
#### getCdpsByOwner
```solidity
function getCdpsByOwner(address owner) external view returns (struct CDPRegistry.CDP[] r)
```
#### getAllCdps
```solidity
function getAllCdps() external view returns (struct CDPRegistry.CDP[] r)
```
#### getCdpsCount
```solidity
function getCdpsCount() public view returns (uint256 totalCdpCount)
```
#### getCdpsCountForCollateral
```solidity
function getCdpsCountForCollateral(address asset) public view returns (uint256)
```
## CollateralRegistry
#### CollateralAdded
```solidity
event CollateralAdded(address asset)
```
#### CollateralRemoved
```solidity
event CollateralRemoved(address asset)
```
#### collateralId
```solidity
mapping(address => uint256) collateralId
```
#### collateralList
```solidity
address[] collateralList
```
#### constructor
```solidity
constructor(address _vaultParameters, address[] assets) public
```
#### addCollateral
```solidity
function addCollateral(address asset) public
```
#### removeCollateral
```solidity
function removeCollateral(address asset) public
```
#### isCollateral
```solidity
function isCollateral(address asset) public view returns (bool)
```
#### collaterals
```solidity
function collaterals() external view returns (address[])
```
#### collateralsCount
```solidity
function collateralsCount() external view returns (uint256)
```
## GCD
*ERC20 token*
#### name
```solidity
string name
```
#### symbol
```solidity
string symbol
```
#### version
```solidity
string version
```
#### decimals
```solidity
uint8 decimals
```
#### totalSupply
```solidity
uint256 totalSupply
```
#### balanceOf
```solidity
mapping(address => uint256) balanceOf
```
#### allowance
```solidity
mapping(address => mapping(address => uint256)) allowance
```
#### Approval
```solidity
event Approval(address owner, address spender, uint256 value)
```
*Trigger on any successful call to approve(address spender, uint amount)*
#### Transfer
```solidity
event Transfer(address from, address to, uint256 value)
```
*Trigger when tokens are transferred, including zero value transfers*
#### initialize
```solidity
function initialize(address _parameters) public
```
| Name | Type | Description |
| ------------ | ------- | ----------------------------------------- |
| \_parameters | address | The address of system parameters contract |
#### \_authorizeUpgrade
```solidity
function _authorizeUpgrade(address) internal
```
Restricted upgrades function
#### mint
```solidity
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*
| Name | Type | Description |
| ------ | ------- | -------------------------------- |
| to | address | The address of the recipient |
| amount | uint256 | The amount of token to be minted |
#### burn
```solidity
function burn(uint256 amount) external
```
Only manager can burn tokens from manager's balance
*Burns 'amount' of tokens, and MUST fire the Transfer event*
| Name | Type | Description |
| ------ | ------- | -------------------------------- |
| amount | uint256 | The amount of token to be burned |
#### burn
```solidity
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*
| Name | Type | Description |
| ------ | ------- | -------------------------------- |
| from | address | The address of the balance owner |
| amount | uint256 | The amount of token to be burned |
#### transfer
```solidity
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.*
| Name | Type | Description |
| ------ | ------- | ------------------------------------- |
| to | address | The address of the recipient |
| amount | uint256 | The amount of token to be transferred |
#### transferFrom
```solidity
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*
| Name | Type | Description |
| ------ | ------- | ------------------------------------- |
| from | address | The address of the sender |
| to | address | The address of the recipient |
| amount | uint256 | The amount of token to be transferred |
#### approve
```solidity
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'.*
| Name | Type | Description |
| ------- | ------- | ------------------------------------------------------ |
| spender | address | The address of the account able to transfer the tokens |
| amount | uint256 | The amount of tokens to be approved for transfer |
#### increaseAllowance
```solidity
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
```solidity
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
```solidity
function _approve(address owner, address spender, uint256 amount) internal virtual
```
#### \_burn
```solidity
function _burn(address from, uint256 amount) internal virtual
```
## CDPManager01
#### vault
```solidity
contract IVault vault
```
#### vaultManagerParameters
```solidity
contract IVaultManagerParameters vaultManagerParameters
```
#### oracleRegistry
```solidity
contract IOracleRegistry oracleRegistry
```
#### cdpRegistry
```solidity
contract ICDPRegistry cdpRegistry
```
#### WETH
```solidity
address payable WETH
```
#### Q112
```solidity
uint256 Q112
```
#### DENOMINATOR\_1E5
```solidity
uint256 DENOMINATOR_1E5
```
#### Join
```solidity
event Join(address asset, address owner, uint256 main, uint256 gcd)
```
*Trigger when joins are happened*
#### Exit
```solidity
event Exit(address asset, address owner, uint256 main, uint256 gcd)
```
*Trigger when exits are happened*
#### LiquidationTriggered
```solidity
event LiquidationTriggered(address asset, address owner)
```
*Trigger when liquidations are initiated*
#### checkpoint
```solidity
modifier checkpoint(address asset, address owner)
```
#### constructor
```solidity
constructor(address _vaultManagerParameters, address _oracleRegistry, address _cdpRegistry) public
```
| Name | Type | Description |
| ------------------------ | ------- | --------------------------------------------------------- |
| \_vaultManagerParameters | address | The address of the contract with Vault manager parameters |
| \_oracleRegistry | address | The address of the oracle registry |
| \_cdpRegistry | address | The address of the CDP registry |
#### receive
```solidity
receive() external payable
```
#### join
```solidity
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*
| Name | Type | Description |
| ----------- | ------- | --------------------------------------- |
| asset | address | The address of the collateral |
| assetAmount | uint256 | The amount of the collateral to deposit |
| gcdAmount | uint256 | The amount of GCD token to borrow |
#### join\_Eth
```solidity
function join_Eth(uint256 gcdAmount) external payable
```
*Deposits ETH and/or borrows GCD*
| Name | Type | Description |
| --------- | ------- | --------------------------------- |
| gcdAmount | uint256 | The amount of GCD token to borrow |
#### exit
```solidity
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*
| Name | Type | Description |
| ----------- | ------- | ---------------------------------------- |
| asset | address | The address of the collateral |
| assetAmount | uint256 | The amount of the collateral to withdraw |
| gcdAmount | uint256 | The amount of GCD to repay |
#### exit\_targetRepayment
```solidity
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*
| Name | Type | Description |
| ----------- | ------- | ---------------------------------------- |
| asset | address | The address of the collateral |
| assetAmount | uint256 | The amount of the collateral to withdraw |
| repayment | uint256 | The target repayment amount |
#### exit\_Eth
```solidity
function exit_Eth(uint256 ethAmount, uint256 gcdAmount) public returns (uint256)
```
Withdraws WETH and converts to ETH
| Name | Type | Description |
| --------- | ------- | -------------------------------- |
| ethAmount | uint256 | ETH amount to withdraw |
| gcdAmount | uint256 | The amount of GCD token to repay |
#### exit\_Eth\_targetRepayment
```solidity
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
| Name | Type | Description |
| --------- | ------- | --------------------------- |
| ethAmount | uint256 | ETH amount to withdraw |
| repayment | uint256 | The target repayment amount |
#### \_repay
```solidity
function _repay(address asset, address owner, uint256 gcdAmount) internal
```
#### \_ensurePositionCollateralization
```solidity
function _ensurePositionCollateralization(address asset, address owner) internal view
```
#### triggerLiquidation
```solidity
function triggerLiquidation(address asset, address owner) external
```
*Triggers liquidation of a position*
| Name | Type | Description |
| ----- | ------- | ------------------------------------------------- |
| asset | address | The address of the collateral token of a position |
| owner | address | The owner of the position |
#### getCollateralUsdValue\_q112
```solidity
function getCollateralUsdValue_q112(address asset, address owner) public view returns (uint256)
```
#### \_isLiquidatablePosition
```solidity
function _isLiquidatablePosition(address asset, address owner, uint256 usdValue_q112) internal view returns (bool)
```
*Determines whether a position is liquidatable*
| Name | Type | Description |
| -------------- | ------- | ---------------------------------------- |
| asset | address | The address of the collateral |
| owner | address | The owner of the position |
| usdValue\_q112 | uint256 | Q112-encoded USD value of the collateral |
| Name | Type | Description |
| ---- | ---- | ------------------------------------------------- |
| \[0] | bool | boolean value, whether a position is liquidatable |
#### \_ensureOracle
```solidity
function _ensureOracle(address asset) internal view
```
#### isLiquidatablePosition
```solidity
function isLiquidatablePosition(address asset, address owner) public view returns (bool)
```
*Determines whether a position is liquidatable*
| Name | Type | Description |
| ----- | ------- | ----------------------------- |
| asset | address | The address of the collateral |
| owner | address | The owner of the position |
| Name | Type | Description |
| ---- | ---- | ------------------------------------------------- |
| \[0] | bool | boolean value, whether a position is liquidatable |
#### utilizationRatio
```solidity
function utilizationRatio(address asset, address owner) public view returns (uint256)
```
*Calculates current utilization ratio*
| Name | Type | Description |
| ----- | ------- | ----------------------------- |
| asset | address | The address of the collateral |
| owner | address | The owner of the position |
| Name | Type | Description |
| ---- | ------- | ----------------- |
| \[0] | uint256 | utilization ratio |
#### liquidationPrice\_q112
```solidity
function liquidationPrice_q112(address asset, address owner) external view returns (uint256)
```
*Calculates liquidation price*
| Name | Type | Description |
| ----- | ------- | ----------------------------- |
| asset | address | The address of the collateral |
| owner | address | The owner of the position |
| Name | Type | Description |
| ---- | ------- | ------------------------------ |
| \[0] | uint256 | Q112-encoded liquidation price |
#### \_calcPrincipal
```solidity
function _calcPrincipal(address asset, address owner, uint256 repayment) internal view returns (uint256)
```
## VaultManagerParameters
#### initialCollateralRatio
```solidity
mapping(address => uint256) initialCollateralRatio
```
#### liquidationRatio
```solidity
mapping(address => uint256) liquidationRatio
```
#### liquidationDiscount
```solidity
mapping(address => uint256) liquidationDiscount
```
#### devaluationPeriod
```solidity
mapping(address => uint256) devaluationPeriod
```
#### constructor
```solidity
constructor(address _vaultParameters) public
```
#### setCollateral
```solidity
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*
| Name | Type | Description |
| --------------------------- | ---------- | ----------------------------------------------------- |
| asset | address | The address of the main collateral token |
| stabilityFeeValue | uint256 | The percentage of the year stability fee (3 decimals) |
| liquidationFeeValue | uint256 | The liquidation fee percentage (0 decimals) |
| initialCollateralRatioValue | uint256 | The initial collateralization ratio |
| liquidationRatioValue | uint256 | The liquidation ratio |
| liquidationDiscountValue | uint256 | The liquidation discount (3 decimals) |
| devaluationPeriodValue | uint256 | The devaluation period in blocks |
| gcdLimit | uint256 | The GCD token issue limit |
| oracles | uint256\[] | The enabled oracles type IDs |
#### setInitialCollateralRatio
```solidity
function setInitialCollateralRatio(address asset, uint256 newValue) public
```
Only manager is able to call this function
*Sets the initial collateral ratio*
| Name | Type | Description |
| -------- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| newValue | uint256 | The collateralization ratio (0 decimals) |
#### setLiquidationRatio
```solidity
function setLiquidationRatio(address asset, uint256 newValue) public
```
Only manager is able to call this function
*Sets the liquidation ratio*
| Name | Type | Description |
| -------- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| newValue | uint256 | The liquidation ratio (0 decimals) |
#### setLiquidationDiscount
```solidity
function setLiquidationDiscount(address asset, uint256 newValue) public
```
Only manager is able to call this function
*Sets the liquidation discount*
| Name | Type | Description |
| -------- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| newValue | uint256 | The liquidation discount (3 decimals) |
#### setDevaluationPeriod
```solidity
function setDevaluationPeriod(address asset, uint256 newValue) public
```
Only manager is able to call this function
*Sets the devaluation period of collateral after liquidation*
| Name | Type | Description |
| -------- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| newValue | uint256 | The devaluation period in blocks |
## 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
```solidity
address payable weth
```
#### DENOMINATOR\_1E5
```solidity
uint256 DENOMINATOR_1E5
```
#### DENOMINATOR\_1E2
```solidity
uint256 DENOMINATOR_1E2
```
#### gcd
```solidity
address gcd
```
#### collaterals
```solidity
mapping(address => mapping(address => uint256)) collaterals
```
#### debts
```solidity
mapping(address => mapping(address => uint256)) debts
```
#### liquidationBlock
```solidity
mapping(address => mapping(address => uint256)) liquidationBlock
```
#### liquidationPrice
```solidity
mapping(address => mapping(address => uint256)) liquidationPrice
```
#### tokenDebts
```solidity
mapping(address => uint256) tokenDebts
```
#### stabilityFee
```solidity
mapping(address => mapping(address => uint256)) stabilityFee
```
#### liquidationFee
```solidity
mapping(address => mapping(address => uint256)) liquidationFee
```
#### oracleType
```solidity
mapping(address => mapping(address => uint256)) oracleType
```
#### lastUpdate
```solidity
mapping(address => mapping(address => uint256)) lastUpdate
```
#### notLiquidating
```solidity
modifier notLiquidating(address asset, address user)
```
#### initialize
```solidity
function initialize(address _parameters, address _gcd, address payable _weth) public
```
| Name | Type | Description |
| ------------ | --------------- | ------------------------------------ |
| \_parameters | address | The address of the system parameters |
| \_gcd | address | GCD token address |
| \_weth | address payable | |
#### \_authorizeUpgrade
```solidity
function _authorizeUpgrade(address) internal
```
Restricted upgrades function
#### receive
```solidity
receive() external payable
```
#### update
```solidity
function update(address asset, address user) public
```
*Updates parameters of the position to the current ones*
| Name | Type | Description |
| ----- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The owner of a position |
#### spawn
```solidity
function spawn(address asset, address user, uint256 _oracleType) external
```
*Creates new position for user*
| Name | Type | Description |
| ------------ | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| \_oracleType | uint256 | The type of an oracle |
#### destroy
```solidity
function destroy(address asset, address user) public
```
*Clears unused storage variables*
| Name | Type | Description |
| ----- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
#### depositMain
```solidity
function depositMain(address asset, address user, uint256 amount) external
```
Tokens must be pre-approved
*Adds main collateral to a position*
| Name | Type | Description |
| ------ | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| amount | uint256 | The amount of tokens to deposit |
#### depositEth
```solidity
function depositEth(address user) external payable
```
*Converts ETH to WETH and adds main collateral to a position*
| Name | Type | Description |
| ---- | ------- | --------------------------------- |
| user | address | The address of a position's owner |
#### withdrawMain
```solidity
function withdrawMain(address asset, address user, uint256 amount) external
```
*Withdraws main collateral from a position*
| Name | Type | Description |
| ------ | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| amount | uint256 | The amount of tokens to withdraw |
#### withdrawEth
```solidity
function withdrawEth(address payable user, uint256 amount) external
```
*Withdraws WETH collateral from a position converting WETH to ETH*
| Name | Type | Description |
| ------ | --------------- | --------------------------------- |
| user | address payable | The address of a position's owner |
| amount | uint256 | The amount of ETH to withdraw |
#### borrow
```solidity
function borrow(address asset, address user, uint256 amount) external returns (uint256)
```
*Increases position's debt and mints GCD token*
| Name | Type | Description |
| ------ | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| amount | uint256 | The amount of GCD to borrow |
#### repay
```solidity
function repay(address asset, address user, uint256 amount) external returns (uint256)
```
*Decreases position's debt and burns GCD token*
| Name | Type | Description |
| ------ | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| amount | uint256 | The amount of GCD to repay |
| Name | Type | Description |
| ---- | ------- | -------------------------- |
| \[0] | uint256 | updated debt of a position |
#### chargeFee
```solidity
function chargeFee(address asset, address user, uint256 amount) external
```
*Transfers fee to foundation*
| Name | Type | Description |
| ------ | ------- | ---------------------------------- |
| asset | address | The address of the fee asset |
| user | address | The address to transfer funds from |
| amount | uint256 | The amount of asset to transfer |
#### triggerLiquidation
```solidity
function triggerLiquidation(address asset, address positionOwner, uint256 initialPrice) external
```
*Deletes position and transfers collateral to liquidation system*
| Name | Type | Description |
| ------------- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| positionOwner | address | The address of a position's owner |
| initialPrice | uint256 | The starting price of collateral in GCD |
#### liquidate
```solidity
function liquidate(address asset, address positionOwner, uint256 mainAssetToLiquidator, uint256 mainAssetToPositionOwner, uint256 repayment, uint256 penalty, address liquidator) external
```
*Internal liquidation process*
| Name | Type | Description |
| ------------------------ | ------- | ---------------------------------------------------- |
| asset | address | The address of the main collateral token |
| positionOwner | address | The address of a position's owner |
| mainAssetToLiquidator | uint256 | The amount of main asset to send to a liquidator |
| mainAssetToPositionOwner | uint256 | The amount of main asset to send to a position owner |
| repayment | uint256 | The repayment in GCD |
| penalty | uint256 | The liquidation penalty in GCD |
| liquidator | address | The address of a liquidator |
#### changeOracleType
```solidity
function changeOracleType(address asset, address user, uint256 newOracleType) external
```
Only manager can call this function
*Changes broken oracle type to the correct one*
| Name | Type | Description |
| ------------- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| newOracleType | uint256 | The new type of an oracle |
#### getTotalDebt
```solidity
function getTotalDebt(address asset, address user) public view returns (uint256)
```
*Calculates the total amount of position's debt based on elapsed time*
| Name | Type | Description |
| ----- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| Name | Type | Description |
| ---- | ------- | -------------------------------------------- |
| \[0] | uint256 | user debt of a position plus accumulated fee |
#### calculateFee
```solidity
function calculateFee(address asset, address user, uint256 amount) public view returns (uint256)
```
*Calculates the amount of fee based on elapsed time and repayment amount*
| Name | Type | Description |
| ------ | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| user | address | The address of a position's owner |
| amount | uint256 | The repayment amount |
| Name | Type | Description |
| ---- | ------- | ----------- |
| \[0] | uint256 | fee amount |
## VaultParameters
#### stabilityFee
```solidity
mapping(address => uint256) stabilityFee
```
#### liquidationFee
```solidity
mapping(address => uint256) liquidationFee
```
#### tokenDebtLimit
```solidity
mapping(address => uint256) tokenDebtLimit
```
#### canModifyVault
```solidity
mapping(address => bool) canModifyVault
```
#### isManager
```solidity
mapping(address => bool) isManager
```
#### isOracleTypeEnabled
```solidity
mapping(uint256 => mapping(address => bool)) isOracleTypeEnabled
```
#### vault
```solidity
address payable vault
```
#### foundation
```solidity
address foundation
```
#### initialize
```solidity
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
```solidity
function _authorizeUpgrade(address) internal
```
Restricted upgrades function
#### setManager
```solidity
function setManager(address who, bool permit) external
```
Only manager is able to call this function
*Grants and revokes manager's status of any address*
| Name | Type | Description |
| ------ | ------- | ------------------- |
| who | address | The target address |
| permit | bool | The permission flag |
#### setFoundation
```solidity
function setFoundation(address newFoundation) external
```
Only manager is able to call this function
*Sets the foundation address*
| Name | Type | Description |
| ------------- | ------- | -------------------------- |
| newFoundation | address | The new foundation address |
#### setCollateral
```solidity
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*
| Name | Type | Description |
| ------------------- | ---------- | ----------------------------------------------------- |
| asset | address | The address of the main collateral token |
| stabilityFeeValue | uint256 | The percentage of the year stability fee (3 decimals) |
| liquidationFeeValue | uint256 | The liquidation fee percentage (0 decimals) |
| gcdLimit | uint256 | The GCD token issue limit |
| oracles | uint256\[] | The enables oracle types |
#### setVaultAccess
```solidity
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*
| Name | Type | Description |
| ------ | ------- | ------------------- |
| who | address | The target address |
| permit | bool | The permission flag |
#### setStabilityFee
```solidity
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*
| Name | Type | Description |
| -------- | ------- | ----------------------------------------- |
| asset | address | The address of the main collateral token |
| newValue | uint256 | The stability fee percentage (3 decimals) |
#### setLiquidationFee
```solidity
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*
| Name | Type | Description |
| -------- | ------- | ------------------------------------------- |
| asset | address | The address of the main collateral token |
| newValue | uint256 | The liquidation fee percentage (0 decimals) |
#### setOracleType
```solidity
function setOracleType(uint256 _type, address asset, bool enabled) public
```
Only manager is able to call this function
*Enables/disables oracle types*
| Name | Type | Description |
| ------- | ------- | ---------------------------------------- |
| \_type | uint256 | The type of the oracle |
| asset | address | The address of the main collateral token |
| enabled | bool | The control flag |
#### setTokenDebtLimit
```solidity
function setTokenDebtLimit(address asset, uint256 limit) public
```
Only manager is able to call this function
*Sets GCD limit for a specific collateral*
| Name | Type | Description |
| ----- | ------- | ---------------------------------------- |
| asset | address | The address of the main collateral token |
| limit | uint256 | The limit number |
# OGXT
**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.
At the core of the exchange token functionality is its focus on the issuance and trading of synthetic assets linked to RWA (real world assets), such as gold, silver, oil, exchange or crypto-indices, ETFs, or stocks and even other cryptocurrencies. The principle for holding the peg is as follows: two pairs of assets are issued for long and short (described [here](https://forum.gton.capital/t/modeling-inverse-mirrored-assets-peg/429)), whereas the peg itself is supported by the Pathway protocol (research [article](https://arxiv.org/pdf/2202.06541.pdf)).
One of the key features of the DEX tokenomics is that the Relay Token ([MoE](https://www.investopedia.com/terms/m/mediumofexchange.asp)), which also serves as the governance token of the exchange, is burned during each swap operation (0.3% fee), thus reducing the circulating supply.
**OGXT Relay Token**
The tokenomics of Ethereum, after the adoption of EIP-1559, is designed to cause Ethereum to become deflationary through fee burning, as activity on the blockchain increases. This is quite simple and effective, as the value of the network grows with the growth of network usage. At the same time, the staking yield stays predictable and can be expressed in terms of APR ([annual percentage rate](https://www.investopedia.com/terms/a/apr.asp)). For example, if the APR is 10% but the Annual Burn Rate (ABR) is higher than 10%, the native token becomes deflationary.
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
# Oracles
SuSy Chainlink Auditor is a fork of Chainlink DON which serves the needs of GTON Network. In order to set up your node, please execute *deploy.sh* from this repository:
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 → OGXT Token Swap
**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.**
As a result of [the recent vote](https://snapshot.org/#/gton.eth/proposal/0x90720b0dc61bd5bb7cfd4378702db69a2a5ccdeb46772c4eccd5a706fb9a25f1) of the DAO community on the [OGXT proposal](https://forum.gton.capital/t/original-gton-exchange-ogxt/430), we have begun the process of gradual exchange of GTON tokens for OGXT tokens. As of March 10, 2023, the DAO-provided liquidity for GTON has been fully withdrawn from all major DEXes.
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.
2. Send the GTON you want to exchange for OGXT to the team's Safe address on Ethereum: [0xbE70EB523398464De569A84F447576f4f169D8d9 ](https://app.safe.global/home?safe=eth:0xbE70EB523398464De569A84F447576f4f169D8d9)Make note of the transaction hash and prepare an Etherscan link of the transaction for the next step.
3. Share the transaction details using [this form](https://forms.gle/rQxGCioVu9w3XpxMA).
4. if you have any issues or questions, open a support ticket on [Discord](https://discord.com/channels/881824930822512660/884746114065125417).
### Stablecoin swap
If you choose to proceed with the swap procedure of GTON for stablecoins, note that the tentative deadline for this option is when OGXT/GCD liquidity will be added on the GTON Chain. As mentioned previously, the swap rate for the stablecoin swap is also fixed at 32 cents per GTON held. This option is subject to a full KYC process, so we ask you to create [a support ticket on Discord](https://discord.com/channels/881824930822512660/884746114065125417) for the team to assist you with this process.
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.
\
# OGXT/GCD Ratio
*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.
# Connect to GTON Testnet
How to connect to GTON Network L2 Testnet over BNB Chain
**Testnet - Goerli**
| Parameter | Value |
| -------------------- | ------------------------------------------------------------------------------ |
| Currency | GCD |
| Chain ID | 50021 |
| HTTP RPC Endpoint | |
| WebSocket Endpoint | wss\://testnet.gton.network/socket |
| Block Explorer | |
| L1 GCD Token Address | |
| L1 Chain ID | **97 (BSC Testnet)** |
### Explorer
\
You can view all deployed contracts and track transactions on the testnet 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.
Approve spending of GCD to the[ L1 Bridge contract](https://testnet.bscscan.com/address/0xbAB11f1161a1E7543B006deFdA0540e05f09bbBF#writeProxyContract).
After that, you can use the [L1 Bridge contract](https://testnet.bscscan.com/address/0xbAB11f1161a1E7543B006deFdA0540e05f09bbBF#writeProxyContract) to bridge the funds.
**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.
# Metamask Settings
| Parameter | Value |
| ------------------ | -------------------------------- |
| Network Name | GTON Network |
| RPC URL | |
| Chain ID | 1000 |
| Currency Symbol | GCD |
| Block Explorer URL | |
Or use [GTON CLI](https://cli.gton.capital/) to add the network, command:\
\
**switch gton**
After creating an Ethereum wallet using MetaMask, you can transfer coins and spend your digital assets on other platforms. Another option to set up a MetaMask connection to GTON Network is by using Chainlist (allows users to search for different digital tokens and easily connect to EVM-powered networks). Use [this link](https://chainlist.org/chain/50021) to add GTON Testnet.
# Deploy to GTON Network
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:
```javascript
module.exports = {
networks: {
...
// for testnet
'gton-testnet': {
url: "https://testnet.gton.network/",
chainId: 50021,
accounts: [privateKey1, privateKey2, ...]
},
},
...
}
```
# Contract Verification
GTON Network hostes a dedicated Blockscout instance to provide blockchain explorer services.
Please use this guide to learn how to verify your deployed contracts:
# Mint & Bridge GCD
GCD can be minted and bridged into GTON Network via [GTON CLI](https://cli.gton.capital/).
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 \ \** \
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:
1. Approve spending of [BUSD](https://bscscan.com/address/0xe9e7cea3dedca5984780bafc599bd69add087d56) to the Vault Proxy contract: [0xAAbBB7471bCA1C152C690f10A1A9e006FE17BD7e](https://bscscan.com/address/0xAAbBB7471bCA1C152C690f10A1A9e006FE17BD7e)
2. Use [CDPManager01](https://bscscan.com/address/0x6aA3cDc7a0Ab05C58105AA4C85568583f2b7e02f#writeContract#F5) contract to execute the Join method for BUSD
# Tech Support
You can ask for assistance in GTON Capital’s Discord server, #support channel, our team members respond most quickly there.
# Positions Liquidation and Closing the Project
In November 2023, the team launched a communication campaign within the GTON Capital community for OGXT holders: [Link](https://discord.com/channels/881824930822512660/882258532764909609/1171057798696665139)
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:
{% embed url="" %}
***
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.
\
# GTON Ecosystem
# Multisig
In GCapital, a DAO, the holders of GTON are vested with a voting power on the direction of Graviton development: the polling of holders’ decisions are conducted through offchain voting, whereas the protocol updates with the associated alterations to the smart contracts require a multisignature procedure. Thus, the smart contracts of the DAO are signed through a multisignature, with the developers of GCapital and various representatives from the most prominent and respected DeFi projects participating as signatories.
The composition of participants will change as the project develops. The exact personal identities of multisig providers will not be revealed, which does not preclude a multisig signatory from disclosing their own identity to the public if they so choose.
**The current line-up of multisig participants (6/10 consensus is required):**
1. Fantom - C-Level Executive
2. Binance Smart Chain - Core Dev Manager
3. 1inch - C-Level Executive
4. LobsterDAO - admin
5. Industry Leader in the Oracles Infrastructure - Core dev team
6. Early Advisor / Investor
7. G21 Team - CTO
8. SuSy Team - Product Owner
9. SuSy Team - CTO
10. YellowBlock - Founding & Influencers team
This two-stage configuration, with voting/proposals by tokenholders and direct alteration of smart contracts via multisig, will ensure an open and transparent development of GCapital and seamless migration of infrastructure-critical smart contracts.
The address of the Multisig contract is: [0x953555e0Af401Bd031a5a53c72EFa81fae464276](https://etherscan.io/address/0x953555e0Af401Bd031a5a53c72EFa81fae464276)
# Treasury Management
In this section we present an approach to treasury management.
### 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:
$$
R\_a= alpha+beta\*R\_m+zeta,
$$
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.
# Treasury Snapshot Reports (TSR)
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.
You can find the contract address of the Treasury [here](https://etherscan.io/address/0x953555e0Af401Bd031a5a53c72EFa81fae464276).
#### Treasury Snapshot Reports
* [TSR 1 - 19 Jan 2022](/treasury/treasury-snapshot-reports-tsr/tsr-1-19-jan-2022)
* [TSR 2 - 19 Feb 2022](/treasury/treasury-snapshot-reports-tsr/tsr-2-19-feb-2022)
* [TSR 3 - 19 Mar 2022](/treasury/treasury-snapshot-reports-tsr/tsr-3-19-mar-2022)
* [TSR 4 - 19 Apr 2022](/treasury/treasury-snapshot-reports-tsr/tsr-4-19-apr-2022)
* [TSR 5 - 19 May 2022](/treasury/treasury-snapshot-reports-tsr/tsr-5-19-may-2022)
* [TSR 6 - 19 Jun 2022](/treasury/treasury-snapshot-reports-tsr/tsr-6-19-jun-2022)
* [TSR 7 - 19 Jul 2022](/treasury/treasury-snapshot-reports-tsr/tsr-7-19-jul-2022)
* [TSR 8 - 19 Aug 2022](/treasury/treasury-snapshot-reports-tsr/tsr-8-19-aug-2022)
* [TSR 9 - 19 Sept 2022](/treasury/treasury-snapshot-reports-tsr/tsr-9-19-sept-2022)
* [TSR 10 - 19 Oct 2022](/treasury/treasury-snapshot-reports-tsr/tsr-10-19-oct-2022)
* [TSR 11 - 19 Nov 2022](/treasury/treasury-snapshot-reports-tsr/tsr-11-19-nov-2022)
* [TSR 12 - 19 Dec 2022](/treasury/treasury-snapshot-reports-tsr/tsr-12-19-dec-2022)
* [TSR 13 - 19 Jan 202](/treasury/treasury-snapshot-reports-tsr/tsr-12-19-dec-2022)[3](/treasury/treasury-snapshot-reports-tsr/tsr-13-19-jan-2023)
* [TSR 14 - 19 Feb 2023](/treasury/treasury-snapshot-reports-tsr/tsr-14-19-feb-2023)
* [TSR 15 - 19 Mar 2023](/treasury/treasury-snapshot-reports-tsr/tsr-15-19-mar-2023)
* [TSR 16 - 19 Apr 2023](/treasury/treasury-snapshot-reports-tsr/tsr-16-19-apr-2023)
* [TSR 17 - 19 May 2023](/treasury/treasury-snapshot-reports-tsr/tsr-17-19-may-2023)
* [TSR 18 - 19 Jun 2023](/treasury/treasury-snapshot-reports-tsr/tsr-18-19-jun-2023)
* [TSR 19 - 19 Jul 2023](/treasury/treasury-snapshot-reports-tsr/tsr-19-19-jul-2023)
* [TSR 20 - 19 Aug 2023](/treasury/treasury-snapshot-reports-tsr/tsr-20-19-aug-2023)
# TSR 1 - 19 Jan 2022
## 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)
Currently, liquidity is mostly concentrated on the Fantom network in SpiritSwap's AMM DEX. However, there are also active pools on Ethereum, Polygon and Binance Smart Chain. In fact, there are many more networks with the $GTON token, however, liquidity on them is still insignificant and will increase in accordance with the [2022 GC Roadmap](https://mirror.xyz/0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0/5mqMhZDc6rmMniG7aE9-R-PBmGMLMjup4MxYv3Qc-q0).
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.**
# TSR 2 - 19 Feb 2022
## 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
# TSR 3 - 19 Mar 2022
GTON Capital's Treasury Snapshot Report for March 2022
### 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.
# TSR 4 - 19 Apr 2022
GTON Capital's Treasury Snapshot Report for April 2022
### 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.
# TSR 5 - 19 May 2022
GTON Capital's Treasury Snapshot Report for May 2022
### 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.
# TSR 6 - 19 Jun 2022
GTON Capital's Treasury Snapshot Report for Jun 2022
### 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.
# TSR 7 - 19 Jul 2022
GTON Capital's Treasury Snapshot Report for Jul 2022
### 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.
# TSR 8 - 19 Aug 2022
GTON Capital's Treasury Snapshot Report for Aug 2022
### 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.
# TSR 9 - 19 Sept 2022
GTON Capital's Treasury Snapshot Report for Sept 2022
### 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
# TSR 10 - 19 Oct 2022
GTON Capital's Treasury Snapshot Report for October 2022
### 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
# TSR 11 - 19 Nov 2022
GTON Capital's Treasury Snapshot Report for November 2022
### 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
# TSR 12 - 19 Dec 2022
GTON Capital's Treasury Snapshot Report for December 2022
### 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
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 15 182 **$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,0672** mln of #POL and **\~$2,588 mln** of #POA
# TSR 13 - 19 Jan 2023
GTON Capital's Treasury Snapshot Report for January 2023
### 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%).
**\~ 59966.62992113622 (0,0599 ml) $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 2 127 488 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 1 457 **$ POA**
Total GTON ≈ 0, 632mln
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 36 647 **$ POA**
Total **GTON**: ≈ 0,572 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 8 139 **$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 1 789 **$ 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.333,47 mln$
**Summary**
According to the March report, the Treasury accounts own **$0,0754** mln of #POL and **$2,508** mln of #POA.
# TSR 14 - 19 Feb 2023
GTON Capital's Treasury Snapshot Report for February 2023
### 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%).
**\~ 53734.316 (0,0537 ml) $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 1 927 661 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 7.68 **$ POA**
Total **GTON** ≈ 0, 621 **mln**
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 58 645 **$ POA**
Total **GTON**: ≈ 0,585 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 12 044 **$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 2 699 **$ 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.333,47 mln$
**Summary**
According to the March report, the Treasury accounts own $0,0537 mln of #POL and **$2,379** mln of #POA.
# TSR 15 - 19 Mar 2023
GTON Capital's Treasury Snapshot Report for March 2023
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.
# TSR 16 - 19 Apr 2023
GTON Capital's Treasury Snapshot Report for April 2023
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%).
**\~ 0 $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 1 726 361 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 28 864 **$ POA**
Total **GTON** ≈ 0,909 **mln**
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 52 829 **$ POA**
Total **GTON**: ≈ 0,585 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 9 300**$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 16 813 **$ 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 April report, the Treasury accounts own $0 mln of #POL and **$2,252** mln of #POA.
# TSR 17 - 19 May 2023
GTON Capital's Treasury Snapshot Report for May 2023
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%).
**\~ 0 $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 1 514 308 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 11 391 **$ POA**
Total **GTON** ≈ 1,654 **mln**
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 37 983 **$ POA**
Total **GTON**: ≈ 0,587 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 7335**$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 94283 **$ 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 April report, the Treasury accounts own $0 mln of #POL and **$2,082** mln of #POA.
# TSR 18 - 19 Jun 2023
GTON Capital's Treasury Snapshot Report for June 2023
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%).
**\~ 0 $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 1 493 048 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 10 918 **$ POA**
Total **GTON** ≈ 2,031 **mln**
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 23 210 **$ POA**
Total **GTON**: ≈ 0,591 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 5202 **$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 39 600 **$ POA**
Total **GTON**: ≈ 0,152 **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 April report, the Treasury accounts own $0 mln of #POL and **$1,988** mln of #POA.
# TSR 19 - 19 Jul 2023
GTON Capital's Treasury Snapshot Report for Jule 2023
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%).
**\~ 0 $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 1 369 039 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 11 782 **$ POA**
Total **GTON** ≈ 2,089 **mln**
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 22 246 **$ POA**
Total **GTON**: ≈ 0,654 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 6384 **$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 1768 **$ POA**
Total **GTON**: ≈ 0,152 **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 April report, the Treasury accounts own $0 mln of #POL and **$1,828** mln of #POA.
# TSR 20 - 19 Aug 2023
GTON Capital's Treasury Snapshot Report for August 2023
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%).
**\~ 0 $POL**
### Main GC Treasury
Address: 0x953555e0af401bd031a5a53c72efa81fae464276
Total: ≈ 1 315 623 **$ POA**
Total **GTON** ≈ 16,57 **mln**
### **ETHNet Ops Treasury**
Address: 0xbE70EB523398464De569A84F447576f4f169D8d9
Total: ≈ 9458 **$ POA**
Total **GTON** ≈ 2,089 **mln**
### FTMNet Ops Treasury
Address: 0xB3D22267E7260ec6c3931d50D215ABa5Fd54506a
Total: ≈ 16 922 **$ POA**
Total **GTON**: ≈ 0,654 **mln**
### MATICNet Ops Treasury
Address: 0x9b28eAB67c14df24FF7E58C6E3f852a0DC41A807
Total: ≈ 4871 **$ POA**
Total **GTON:** ≈ 0,055 mln
### BSCNet Ops Treasury
Address: 0x93b443d1f4081b58de5ca637d63e49880c04ac4a
Total: ≈ 1 512 **$ POA**
Total **GTON**: ≈ 0,152 **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 April report, the Treasury accounts own $0 mln of #POL and **$1,765** mln of #POA.
# TSR 21 - 27 Feb 2024
GTON Capital's Treasury Snapshot Report for February 2024
# ⚠️Legal Disclaimer
Please note that this site is operated by GTON Capital DAO (a decentralized autonomous organization), and you are solely responsible for compliance with all laws that may apply to you and your use of GTON Capital products. Cryptocurrencies and blockchain technologies have been the subject of scrutiny by various regulatory bodies across the globe. GTON Capital makes no representation regarding the application to your use of GTON Capital products of any laws, including, without limitation, those related to gaming, options, derivatives, or securities. Depending on the jurisdiction, the use of GTON Capital products may be restricted. You agree that GTON Capital DAO is not responsible for determining whether or which laws may apply to you and your use of GTON Capital products. GTON Capital may restrict the use of its products to citizens and residents of certain jurisdictions. Nothing in our documentation should be considered financial advice or an endorsement to purchase, deal, market, or arrange for dealing in securities.
#### ⚠️ Particular restrictions
Please note that US residents are strictly prohibited from purchasing or staking crypto assets using GTON Capital platform or GTON Capital Ecosystem products (Candy, OGS, Susy). Further, restricted persons should not interact with the GTON Capital website at any time. By interacting with any smart contract on the GTON Capital protocol (including purchases via bonding, staking, withdrawals, approvals), you expressly and unconditionally affirm that you are not a resident of the US.
# Code of Conduct
Crypto projects, but GTON as a DAO in particular, are dependent on active and constructive community engagement. Building a strong base of GTON governance participants and supporters is of high importance for the success of the :classical\_building:DAO.
Reflecting on the last months of our community journey, we are proud to have gained a growing number of committed members that share the team’s vision and support us with valuable contributions. Nonetheless, we have also seen that constructive discussions were often disturbed by short term market movements, which have direct impact on the communities sentiment leading to ever repeating price-related negativity, FUD or wrong and baseless assumptions. Even though these kinds of reactions are to be seen quite often within crypto communities, we strongly believe that they are highly destructive for any community building and engagement as well as the team’s focus on project development. In addition, community feedback oftentimes comes in the form of critics without deeper fundamental or technical context. As we understand how important feedback and engagement is for ⚜️𝔾ℂ, we want to encourage our community to always add value to their feedback, whenever potential room for improvement has been identified.
Therefore, for onboarding new members but also for the sake of positivity and productivity, a strict Code of Conduct is being introduced to our Discord, Telegram or Twitter channels and forum:
### No negativity
Feedback is always welcome, but baseless and frustration driven complaints that do not help improve the project will be subject to muting. Any kind of community feedback should come in a constructive manner, adding value through actual ideas, solutions and proposals, that in turn could help the core team improve ⚜️𝔾ℂ.
### No objectionable content
Posts including advertisements, FUD, fake news or any illegal content are not allowed and will be removed. Authors of such content will face immediate ban.
### No disrespect
Our channels are a place for positive communication. Any type of disrespectful, violent or threatful behavior towards the team or other community members will not be tolerated.
### No speculation
Any kind of market, trading and price conversations will be allowed only in the dedicated channels.
### No shilling
Don’t shill tokens that have no relation to the ⚜️𝔾ℂ ecosystem. We encourage only meaningful discussions, and in this case you can mention other projects’ tokens. Aggressive shilling and spamming with messages will be banned along with users spreading them out.
Our main communication channel will be transitioned to Discord, as it allows us to manage our growing ecosystem and community in a more suitable way with a diverse set of sub-channels. Nonetheless, and even though we want to encourage our community to join and actively participate in our Discord, the core team will continue maintaining our Telegram community and announcement channels for the time being. Feedback and bug reports can also be given in the forum, through feedback forms, our official Twitter channel or a live chat functionality on the website.
# Legacy Articles
# 🪙Staking
You can stake GTON in the GTON Capital app here: **📺** \
\
Tokens are distributed according to the parameters previously voted upon by the community: GTON staking with **22.32% fixed APR** with daily reward harvesting.
*Example*: Every 100 staked GTON will generate \~2 GTON for the staker every month, with reward distribution happening each block, i.e. \~1 per second.
### **How to harvest rewards?**
Once you add GTON to staking, sGTON is being minted that represents your GTON harvest balance. \
\- You can withdraw GTON from staking or increase the staking balance at any time. \
\- You can withdraw your rewards in sGTON as GTON by calling harvest command once per day. When you harvest, sGTON converts into GTON automatically. \
\- You can also reinvest your harvested GTON by sending it to staking in order to generate more rewards, so your sGTON balance will be increased.
### Why is Staking needed?
* To let holders keep and accumulate GTON over time: accumulation as the basic use case.
* Tokens being put in staking will reduce the circulating supply, thus making GTON a deflationary currency.
* At a later stage, staking will be used for governance and block mining consensus in GCNet.
* Staking is also a tool for designing flexible and scalable governance models and incentivization systems such as delegated governance.
* Staking will be used in the upcoming "growth hacking" strategies such as referral or ambassador programs.
* Staking is a sustainable revenue model for system contributors.
### How to find a sustainable APY?
* First of all, the parameters are not hard-coded and can be redefined by the DAO at any time based on the ongoing market dynamics, product use cases, or any other consideration.
* GC is, first and foremost, an ecosystem of products, with a goal of eventually transforming into GCNet (L1). If we apply statistics, the APY must be comparable to the staking value of the DeFi tokens and L1 staking parameters:
* Based on data, the average of CAKE (60% APY), FTM (10%), BNB (19%), SOL (7%) yields 25% APY for GTON.
* 25% APY equals to 22.23% APR according to
* With 25% APY, a GTON holder who staked 1000 GTONs will receive 250 GTONs by the end of a year.
### How much should we allocate for Staking rewards?
* According to the 🧬PW v1.x DAO vote, we agreed to have \~25% circulating supply at the end of the period (20 epochs). Therefore, the circulating supply will be 0.25·21mln = 5.25mln GTONs. 25% of this amount can be released in the form of staking rewards, which gives us 1.3 mln GTONs (\~6% of TS) allocated for Staking (max allocation, most likely will be less).
### Will APY be fixed, meaning no dilution with new staking deposits coming?
* Yes, APY will be fixed until the next ⚜️GC-🏛DAO vote (ideally in 20 epochs).
### What is sGTON?
* sGTON is the staked GTON - a transferable token for voting/transfer purposes.
##
# 🪢Bonding
Bonding is a GTON Capital revenue generation protocol and the main source of AMM liquidity for GTON. Bonding enables users to buy GTON from the treasury with a discount.
Bonding is a mechanism of liquidity accumulation by CTON Capital 🏛 through selling GTON to potential holders with a discount. Some specific features of GTON Capital bonding mechanism
### What is bonding in GTON Capital?
* Bonding is a GTON Capital revenue generation protocol and the main source of AMM liquidity for GTON (POL, protocol owned liquidity).
* A buyer interacts with a smart contract to buy a locked GTON allocation.
* The locked allocation is stakable to make B attractive, therefore Zap-Bonding-Staking (ZBS).
* Bonding is a fundamental factor for 🧬PW because it attracts new liquidity to AMMs and pushes PWPeg up.
### What are bonding parameters?
There are two types of bonding:
1. **Short-term bonding (STB)**
**1 week lock (\~7 days)** with daily linear unlock starting from +1 day after lock tx. Discount Rate is **7%**. Permissionless.
2. **Medium-term bonding (MTB)** \
**3 months lock (\~90 days)** with daily linear unlock started from +1 day after lock tx. Discount Rate is **15%**. Permissionless.
### How big is the bonding allocation?
* According to the 🧬PW v1.x DAO vote, we agreed to have \~25% circulating supply at the end of the period (20 epochs). Therefore, the circulating supply will be 0.25·21mln = 5.25mln GTONs. 25% of this amount can be released in the form of staking rewards. So, 1.3 mln from that is allocated for 🪙Staking, which means we can set up 5.25 - 1.3 - 2.1 = 1.85 mln (\~9% supply) GTONs for bonding.
* STB allocation is 1.2 mln GTONs (\~2/3 of bonding allocation) and BTB is 0.65 mln GTONs (\~1/3 of bonding allocation).
### Where do the numbers come from for 🪢bonding?
* OlympusDAO discount rates and vesting is used as a reference.
* Those discounts are correlated with weekly and monthly volatility for GTON.
* 75 days loyalty insight from this research:
### What are the features of ZAP (ZBS, Zap-Bonding-Staking)?
All GTONs locked via bonding also automatically generate APY from staking.
### Activation terms & Limits
After the [DAO vote,](https://snapshot.org/#/ftm.gton.eth/proposal/0xf02672701530056d3317975896f48665e705a24a0cecea937fcea7399b130dca) bonding is only activated when the price is above **$5** and can be halted if the price falls until it recovers to the $5 level.
To prevent big players from draining the entire bonding allocation, we impose limit terms: bonding campaigns run a limited number of times, **short-term bonds up to 6 times** per year, **medium-term bonds up to 4 times** per year.
The bond limit per whitelisted address is **100 000 GTON**. The bonds will be sold in allotted **7 day time periods,** which will be announced 6 and 4 times per year for short-term and medium-term bonds, respectively.
### Whitelisting
To increase the number of engaged users, we are introducing a referral program, which will soon be available in the CLI and covered in a separate blog post. Each whitelisted user can whitelist 3 non-whitelisted addresses, and the referral gets to buy bonds from the referrer’s whitelist allocations with the same purchase limit (up to 100 000 GTON).
### How do bonds work?
By purchasing a bond, the user buys GTON directly from the Treasury, but at a fixed discount to the current market price of GTON, locked for a fixed period of time. The bondholder’s return depends on the price of GTON at the time when the bond expires, however the return on investment should also include autostaking applied to the bond at the time of vesting.
Technically, with a bond, the user buys sGTON, which represents staked GTON, in the form of an NFT storing the details of the position (amount, time of purchase, bond expiration date etc).
During the vesting period, the bond increases its value in GTON via in-built staking: as long as the user holds a bond, the **22,32% APR** in GTON is accrued. Thus, Bond NFTs could be the basis of an exciting new class of DeFi derivatives.
A bond NFT can change hands as often as necessary until its lifespan runs out, at which point the current owner can unlock the liquidity.
When an NFT expires, it can be burned to use sGTON (still in staking) without any additional action to put GTON into staking: the staking reward generation continues as soon as the NFT is burned and sGTON unlocked. However, if the user intends to use actual GTON (for trading/farming in other DeFi applications) they will have to unstake GTON i.e. exchange sGTON to GTON.
### Use of treasury funds
The first use of the funds coming from the bonds into the Treasury reserves is to create a large USDC/GTON liquidity pool on Uniswap as part of the [Roadmap](https://mirror.xyz/0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0/5mqMhZDc6rmMniG7aE9-R-PBmGMLMjup4MxYv3Qc-q0).
### What is more profitable, bonding or staking?
Bonding will be more profitable than staking at some point\
However, STBs are restricted in terms of amount and “bond sale” campaign time limits.\
If bond sales events only happen once per 2 months, it only yields 42% ROI in GTON.\
\
For MTBs, there are no time limits since it is only possible to repeat it 4 times, which is 4\*15 = 60% ROI in GTON.\
\
Therefore, there are 3 strategies:\
\
⚜️ Buy and stake: 23% APR (25 APY with compounding)
⚜️ Active 7d re-bonding: \~45% ROI \
\
⚜️Active 3m re-bonding: \~63% ROI\
\
Different strategies have different pros/cons, but they all are needed to generate revenue for CTON Capital.
# 🧬Pathway (PW)
Automated Liquidity Management Protocol controlled by DAO
Pathway (PW) is a DAO-based approach to automated management of so-called POL (protocol-owned liquidity) with the potential to become a new standard of liquidity management. We believe that the implementation of such mechanics can increase market efficiency and prosperity of DAO systems and their token holders through positive feedback loops that correlate with the fundamental growth factors of a token.
### Token Utility
In various applications where digital assets are used, their utility may differ within the product itself: the most common examples are staking, collateralization, governance, fees distribution, or playing a role of native token. Two fundamental factors that are usually measured for utility assets are liquidity and volume.
Liquidity measure represents an amount of capital that can be liquidated or acquired without a significant impact on the market. This is one of the most important fundamental indicators of asset health, as it shows market depth or how much active capital has already entered the system and is used in it. The more liquidity, the greater the capacity of capital that can be invested in an asset, and the higher the safety and freedom of action for an investor.
The value of a utility token is indirectly reflected in how much activity is performed with the asset. In financial protocols, trading volumes are a direct metric of activity around an asset.
### DeFi 2.0
Having started as an alternative to liquidity mining (AMM LP), DeFi 2.0 approach is deemed more promising and fundamentally stable. It is based on creating systems that can coordinate within a DAO structure to collectively manage capital in a treasury and liquidity on the market by solving the main problem that contributes to the instability of financial protocols: [prisoner's dilemma](https://academy.binance.com/en/glossary/prisoners-dilemma). DAOs are capable of negating such economic side effects, as they allow for the creation of robust governance institutions and higher-level protocols, which is necessary for efficient [Digital Capital Markets](https://q-4.capital/digital-capital-markets/).
DAOs are rule-setters for algorithmic systems rather than the systems themselves. When it comes to market making of project tokens or liquidity management, algorithmic systems are needed that will operate in a fully automated manner, but with an ability to be customized and updated through social consensus DAOs. Each such DAO has a treasury which stores assets ([PCA, protocol controlled assets](https://docs.tokemak.xyz/protocol-information/key-terminology#pca-protocol-controlled-assets)) or liquidity ([POL, protocol owned liquidity](https://medium.com/despread-creative/can-protocol-owned-liquidity-be-defi-2-0-d333484578d6)). The last two terms are the basis of DeFi 2.0, but we are expanding their meaning through the introduction of the term Pathway, which is an algorithm for management of the PCA and POL, based on a set of rules and algorithmic parameters which are subject to voting of the DAO.
### Pathway
This article describes the Pathway protocol, primarily how the token value is linked to the fundamental indicators such as liquidity and activity (volumes).
#### Numerical model
The mathematical relation between liquidity and the ratio was deduced based on the analysis of fundamental stats of prominent DeFi projects, such as ANY, OHM, TOKE, and a few others.
To suggest Pathway parameters for the **v1.x settings** we used OlympusDAO ($OHM) as a reference.
Why?
* DeFi 2.0 with same POL model
* Most (> 95%) liquidity on DEXes (Sushi)
* 11 Dec
* Liquidity: $11mln 2% Market Depth → $0.55 bln AMM TVL on Sushi (DAI, ETH, WETH pools)
* MCap: $3bln
* Vol: $90mln
Let's assume that our time target is 20 epochs. Epochs are weeks or 10 days periods. No strict planning is possible due to market volatility, so we should build upon some rough timing assumptions. These parameters are being established for 180+- days, or half a year. The overall time period of Pathway activity is irrelevant because in reality the achievement of the target can take a longer or shorter period depending on the market, community, and team performance.
Assuming that we have 25% of GTON in circulation during Pathway (PW) operation, which includes EB, current liquidity, and Ops & SPI allocations aimed to maintain PW and various supportive features (bonding, Candy and IDOs).
Based on the analysis of the $OHM case, we’re aiming to reach $3bln MCap, thus the max target for PWPeg (Pathway Peg Price - MaxPWPeg) is $600 per $GTON.
Other parameters are following a similar logic, therefore:
* MaxPWPeg = $600
* MaxLiq = $550 mln
* FloorPWPeg = $2.26 (as determined in [Proposal on Pathway parameters: Settings v1.x](https://snapshot.org/#/ftm.gton.eth/proposal/0x8c78c0420928f29befcefb23ec7aa58aa0ef3a46b26d9960d2f9a0caec60b9d5))
#### Pathway v1.x
Thus, the liquidity-only version of Pathway is deducted based on the following formula:
PWPeg (*L*) = **FloorPWPeg** + **MaxPWPeg**\*(*L*/**MaxLiq**), where L is current GTONs liquidity.
For practical implementation we also have to define "tuning" parameters:
* SmoothingFactor for *L - "alpha" parameter exponential averaging of price and liquidity data provided from oracles. We need averaging to prevent PW manipulations from external* malicious actors.
* PegActionFrequency - how often SC will peg the price to the **PWPeg**
* VRF parameters - randomizer parameters to prevent malicious arbitrage activity.
Since liquidity is put in the BASE & QUOTE pair, it grows if there is a growing demand for the BASE token. Thus, the actual mathematical dependency represented by this function isn’t linear, but rather parabolic and depends on the ratio itself.
### Implementation
There exist a number of potential issues that can emerge when implementing Pathway in practice, including but not limited to determinism, the influence of arbitrage, and the risks of manipulation and frontrunning.
In order to mitigate those issues, the system should be adjusted by introducing randomness into the actions that the DAO conducts with the Treasury. For instance, using VRF (verifiable random function) oracles is possible to determine if an action (buy or sell) should be done at the current block.
Another issue that is likely to be encountered is manipulation during the early stage of low liquidity and volume. To prevent this, moving averages, such as the exponential moving average, can be applied. Also, a temporary moratorium for launching Pathway can be introduced by the DAO to lower the risk of such manipulations.
In addition, it is important to note that this protocol can be implemented independently on different blockchains, with arbitrageurs synchronizing the volume, liquidity and price across all chains. A special DON (decentralized oracles network) is planned to be used to synchronize smart contracts between blockchains.
# PW FAQ
Please note that this page is updated frequently.
### What is Pathway?
Pathway is a pricing algorithm used by GC DAO that conducts liquidity operations on AMM DEXs with GTON liquidity that belongs to the DAO (also called protocol-owned liquidity, POL).
### What problems does GC solve with Pathway?
In the traditional, passive approach to DAO-operated liquidity, the market value and the intrinsic value of a DAO token are correlated weakly. The market value stability is disrupted by external noise, intricacies of traders’ behavior, as well as incomplete or asymmetric information.
Algorithmic governance tokens, on the other hand, can use proactive liquidity management strategies in order to smooth and stabilize the price of the token by linking it to an intrinsic value peg. We believe that the implementation of such mechanics can increase market efficiency and prosperity of DAO systems and their token holders through establishing positive feedback loops that correlate with the fundamental growth factors of a token.
Pathway protocol is a tool that DAOs can use to 1. formalize a set of fundamental factors that influence the pricing of a token and 2. establish a market making system that amplifies and sustains the correlation between intrinsic and market values.
GC is, first and foremost, a DAO that aims to generate value for the holders of $GTON governance token. Pathway protocol is used to algorithmically peg $GTON to a weighted sum of tracked performance parameters of the DAO. Through Pathway, $GTON becomes an algorithmic governance token (AGT), and thereby, GTON’s price will tend to stay within a specific corridor, while being dependent on the fundamentals voted by the DAO. We see Pathway as one of the key features of GC which will distinguish it from other DeFi projects.
### What is POL (protocol owned liquidity)?
POL (protocol owned liquidity) describes an approach to liquidity management where LP-tokens are owned and managed collectively by a DAO. It is used to bypass a common problem in DeFi which is the constant need of attracting and retaining liquidity for the token. The POL concept was pioneered by Olympus DAO. One of the difficulties in the practical implementation of Pathway is related to liquidity ownership. For the protocol to perform successful interventions, the DAO should own most of the liquidity for its token. The proportion of POL determines the level of control that the DAO has when attempting to achieve a peg. The exact way of structuring the DAO to ensure liquidity accumulation in the form of POL can be implemented in various ways: one of such ways is bonding, that is, a sale of staked governance token allocations which become an integral part of the governance token liquidity.
### How much of the liquidity share is owned by GC DAO?
The current estimate is at almost 99%. For more information, please follow the [upcoming Treasury Snapshot Reports](/treasury/treasury-snapshot-reports-tsr).
### What is Intrinsic Value?
Intrinsic value is a measure of what an asset is worth. This measure is arrived at by means of an objective calculation or complex financial model, rather than using the currently trading market price of that asset. In GC documentation, the intrinsic value will usually be referred to as “peg price” or simply peg.
### Is there research that Pathway is based on?
For a formalized and generalized explanation of Pathway’s approach, please see [the Pathway white paper](https://arxiv.org/pdf/2202.06541.pdf).
### How are the fundamental metrics to peg to determined?
GC DAO uses DAO governance to determine a set of fundamental metrics that should influence the pricing of GTON. GC DAO’s revenue model is not limited to managing and balancing a portfolio of assets, but is oriented towards achieving development goals. Therefore, a more flexible model based on a set of factors can be applied.
GC DAO will convene regularly to collectively determine: a list of numerical factors that reflect the success of the DAO, for instance: liquidity, active users, integrations, transactions, revenue, assets under management. impact coefficients (weights) of these factors.
### What is a Pathway intervention?
Intervention is a liquidity operation procedure initiated by a DAO MM, which is aimed at adjusting the market price towards the peg (intrinsic value) price by conducting operations with POL. There are two types of Intervention: Up-Intervention which moves the market price up towards the peg, and Down-Intervention which moves the price down (both cases are symmetrical due to the nature of constant product market making AMM).
To conduct an intervention that changes the price, the DAO should algorithmically remove a calculated amount of the governance token, while the quantity of the market token (quote) should remain the same, and do a token swap.
In the perfect scenario, all assets contained in the AMM pool are owned by the DAO. This can also mean that no extra funds in the governance token can be made available to change the market price. If there are no extra funds at DAO’s disposal (e.g. from the treasury), the amount of the market token must remain the same after Up-Intervention. Therefore, an approach is needed that avoids using any extra funds to conduct the swap, extracting the necessary amount from liquidity instead.
In pools on AMM DEXs, the total amount of liquidity the user is able to remove is equal to their share represented as an LP token. LP tokens essentially represent a pair of the tokens in the pool.
In order to execute an Up-Intervention, the MM must withdraw (“burn”) a certain amount of LP tokens (calculated by the Pathway algorithm) from the pool and swap tokens through the same pool to adjust the price. As a result, such Up-Intervention will increase the market price of the governance token, occurring due to the removal of some G tokens from the pool, while the total liquidity will remain the same.
### What are potential implementation difficulties and strategies to counteract them?
Perhaps the most important issue we see that can influence Pathway’s deployment is the probability of front-running transactions that can undermine DAO interventions. In this case, we envision two practical strategies for protection.
With the first strategy, a threshold for the price difference from the oracle and the AMM pool is established at the time of execution. This is analogous to slippage tolerance in AMM DEXs. However, we consider this kind of protection strategy comparatively weak.
The need for time randomization stems from potentially occurring frontrunning transactions. In a fully deterministic system, an external actor can execute a transaction to front-run the intervention and make guaranteed profit.
In order for the protection to be sufficiently strong, a VRF (verifiable random function) randomizer should be employed at the time of intervention execution, which makes it known whether the transaction will be executed or rejected only at the time of execution. With this strategy implemented, front-running will be more risky for the frontrunner, as it does not guarantee any yield but forces the frontrunner to enter a token position.
To sum up, randomization makes this process uncertain for attackers, as it is impossible to know when an intervention transaction will happen and how much random noise is added to the peg, i.e. small fluctuations around peg price in both directions. Therefore, no guaranteed profit exists + there’s an added risk of entering a position.
### Is Pathway already used in production?
Pathway is already in production: v0 (testing version) was launched in December 2021, v1 (stage 1 with a minimum of tracking metrics) will be launched in Q2. For more information on the next steps for GC DAO, please see [the GC 2022 roadmap](https://mirror.xyz/0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0/5mqMhZDc6rmMniG7aE9-R-PBmGMLMjup4MxYv3Qc-q0).
### Where to see Pathway source code?
The primary repository for Pathway: [https://github.com/GTON-capital/pw ]()
# 👼Angels
Since the launch of GTON, the team has been in close contact with our community and certain members in particular, who held an informal advisory role supporting GTON the last few months. This role was a natural development due to the exposure and involvement that these community members have in GTON. The team realized that leveraging this potential could enable the expanse of our core team’s competencies and help the project’s long term growth.
**A special role called** 👼**Angels is therefore established, these are GTON holders:**
* with more than $100k value of GTON (at the moment of qualification based on transaction proofs),
* that can add non-financial value to the ⚜️𝔾ℂ ecosystem (discussed individually upon qualification process)
Trusted GTON holders that are already qualified and engaged in an informal way, will be approached by the core team. GTON holders, that are not yet engaged but feel qualified for an active 👼Angel role, will be given the chance to apply to the Angel program. The qualification process will begin at the end of Q1 2022.
👼Angels will be chosen and qualified by the core team and their own discretion, based on the above mentioned criteria. The qualification of Angels will be reassessed every quarter and adjusted if necessary. The identities of the 👼Angels will remain undisclosed unless an Angel individually decides to publicly disclose their involvement.
Angels can, in accordance to their respective competencies, be involved as advisors in early phases along all areas of ⚜️𝔾ℂ, e.g. from the evaluation of new partnerships, products and strategies to R\&D and technical considerations - if the core team sees any benefit in involving certain:angel: Angels in these areas.
👼Angels can, in accordance to their respective competencies, be included as advisors in conversations with SPIs (strategic partners and investors), CEXes, Design/Development/PR/Legal agencies and other counterparties essential for project development and growth - if the core team sees any benefit in adding certain 👼Angels to these conversations.
The establishment of the angel role is necessary so that qualified GTON holders can be officially enabled to support the team along all ⚜️𝔾ℂ areas and developments. In order to fulfill their role, they can be given access to relevant information that may be subject to certain public restrictions: early internal evaluation, communication with SPIs and terms and conditions (assignments, mutual requirements, discounts and entitlements), agreements with CEXs, new key contributors, new advisors / Influencers and PR / Design / Dev / HR / Legal and other categories of agencies either fall under private communications or are subject to NDAs, or other legal, business or competitive restrictions and will therefore only made available to qualified 👼angels.
We want to emphasize that this new role will neither have an impact on the overall GTON governance model nor on the transparency towards our community and should only be seen as a formalized advisory role for qualified GTON holders, which have mostly been highly engaged in an informal way throughout 2021 already.
Further roles might be added in the future according to potential new ⚜️𝔾ℂ requirements. Decisions on new roles are due to governance proposals and corresponding votes.
# Timeline Overview
GTON Capital started as a DAO in the beginning of 2021, focused on creating a decentralized finance protocol for boosting interchain liquidity based on $GTON token.
At the end of April 2021, the DAO raised $4.7 mln into a Treasury from 325 contributors (so-called Early Backers), with a 10% GTON reward allocation & 3% DEX liquidity allocation established.
During the Q2-Q3 of 2021, GTON was launched on several blockchain networks while establishing at least seven strategic partnerships.
In October 2021, the so-called [Occam's proposal](https://medium.com/graviton-one/occams-proposal-for-graviton-ec2ebec575eb) was proposed by the team and accepted by the community, and the Early Backers allocation was fully unlocked subsequently.
Afterwards, [new narratives](https://mirror.xyz/0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0/voFzw2tuUF275rgwaTdos8CuCKg6B5K5CWzMz7GLjXg) were envisioned & [a new roadmap](https://mirror.xyz/0x8c8b81208C7B7F71CD3279A31F48F1A37bda5df0/5mqMhZDc6rmMniG7aE9-R-PBmGMLMjup4MxYv3Qc-q0) was adopted and launched at the end of 2021.
# Unlocking from staking v0/v1
Guides on migration from halted staking versions
### How to unlock GTON from staking v0
GTON staking was first introduced shortly after the GTON token IDO in May 2021. At that time staking was available on graviton.one website.
Staking v0 was halted in early 2022 due to the rebranding of Graviton to GTON Capital and move to CLI (Command-Line Interface).
#### To check your balance
* Go to this contract:
* Make sure you’re connected to Fantom opera in MetaMask.
* Call the “balance” function with parameters: userChain: EVM userAddress: YourAddress Get the balance number (number of GTON on your balance with decimals).
#### To unlock your staked GTON from staking v0 follow the steps:
* Go to this contract: ;
* Press “Connect to Web3” and connect your MetaMask. Sometimes you have to do it twice till the green light appears.
* Use the “claim” function by entering your balance (number with decimals).
* Click “Write”.
* Confirm the transaction in the MetaMask’s pop-up.
* You can now see GTON on your MetaMask balance.
If everything is okay, MetaMask will show a standard transaction pop-up, if there is insufficient funds for the number entered – it’ll show a transaction with an enormous gas number, so just double check if the number you’re entering is correct.
### How to unlock GTON from staking v1
Following the audit of the staking v1 contract, a migration to staking v2 is to be conducted. To migrate to it once it is deployed into production, you will first have to unlock your staked GTON in order to move it to the updated staking manually through the smart contract.
#### To unlock your staked GTON from staking v0 follow the steps:
* Go to the staking contract on FTMScan: ;
* Make sure you’re connected to Fantom opera in MetaMask.
* Click on the “Connect to Web3” button.
* Scroll till the “WithdrawGTON” field and click on the “Write” button.
* Confirm the transaction in the MetaMask’s pop-up.
* That’s it, your GTON is now in your MetaMask. You’ll be able to add it to staking v2 once it’s live, and we’ll provide a separate guide then.
Please note that sGTON that you will have left on your wallet after claiming GTON is not usable anymore.
# 2021 Vision
In this section we describe the basic features of the GTON Capital
⚜️GC is, first and foremost, a🏛DAO that generates value for the holders of $GTON governance token. $GTON is pegged algorithmically to the tracked fundamental parameters of the DAO via 🧬 Pathway protocol.
### $GTON
$GTON is the governance and utility token for the GTON Capital Ecosystem. Its value is supported by the three key use cases:
* as DAO governance token;
* as a reserve currency;
* as a relay token.
The status of $GTON as a reserve currency can be attained through proactive treasury and liquidity management implemented through Pathway.
#### GTON Smart Contract Addresses
GTON on Ethereum: [0x01e0E2e61f554eCAaeC0cC933E739Ad90f24a86d](https://etherscan.io/token/0x01e0E2e61f554eCAaeC0cC933E739Ad90f24a86d)
GTON on Fantom: [0xC1Be9a4D5D45BeeACAE296a7BD5fADBfc14602C4](https://ftmscan.com/token/0xC1Be9a4D5D45BeeACAE296a7BD5fADBfc14602C4)
### 🧬 Pathway
GC is a DAO that manages POL (Protocol owned assets) ($GTON LPs) based on an approach called Pathway (PW).
The sustainability of the whole GCEco is insured by Pathway - algorithmic liquidity management protocol controlled by the DAO, based on liquidity and volume growth and used to create feedback loops around key GTON metrics.
More information on Pathway can be found on [the next doc page](/history-and-legacy/legacy-articles/pathway-pw).
### 🪢 Bonding
It is necessary to accumulate funds in the Treasury in order for the tokenomics to remain stable in the long-term. Thus, a mechanism is needed to attract borrowed funds for a discount on the tokens in the Treasury with vesting, or a bonding mechanism. This mechanism can be used both with LP tokens with GTON, and with the tokens that form the majority of treasury reserves.
Bonding is a mechanism of liquidity accumulation by the DAO through selling GTON to potential holders with a discount (thus "bonds") for USDC, ETH or Fantom with a configurable ROI and vesting. Users can therefore onboard by picking from a range of parameters among several proposed options.
### 🪙 Staking
GTON can be locked on a smart contract to generate passive staking rewards with a fixed APY: this can be done through a GTON Capital Staking dApp. Staking allows one to accumulate GTON, and reduces the overall circulating supply, thereby leading to a tokenomics which is more sustainable over time. Staking also allows for implementing a delegated governance model: users can commit their GTON balances as votes which are used to elect a number of delegates who make decisions on how GC should evolve as a DAO.
You can stake GTON in the GTON Capital app here: **📺**
# GTON Token
This page contains all you need to know about the GTON Capital's governance token
$GTON - governance & staking token for ⚜️GC 🏛DAO
#### Supply:
* Total supply: 21 mln
* Circulating supply: 15%
* DAO Treasury holdings: 85%
#### Release strategies:
* 🪙Staking: **fixed APY (25%)** staking
* POAP NFTs as yield boost for staking
* AMM allocation for GCEco tokens
* SPI allocation: vested in a form of custom bonds
* Core contributors allocation: in a form of bonds
(!) all DAO treasury allocations and strategies are subject of the DAO voting.
#### Token allocations:
* **15%** - community holdings (staking, wallets, exchanges)
* **20%** - vested core contributors allocation
* **65%** - DAO treasury allocation (split on Ops, 🪙Staking, 🪢Bonding and ecosystem protocol allocations).
(!) all DAO treasury allocations and strategies are subject to the DAO voting.
#### Token economy:
* $GTON is a governance token for GC DAO
* $GTON is one of the collateral tokens for $GCD
* $GTON is a staking token of the ecosystem
