# Introduce
FON Smart Chain is a brand new public chain. The FON Smart Chain relies on a system of 21 active validators with a Proof of Stake (APoS) consensus that supports short block times and low fees. The validator candidate with the most stake will become a validator and produce blocks. Double-signature detection and other slashing logic guarantee security, stability, and chain finality. In addition to the 21 active validators, FSC will also introduce more validators, such as another 20 inactive validators, as backups into the validator set, which will be called "candidates". Candidates will generate blocks and collect gas fees in the FSC Mainnet, but have far fewer chances than the formal validator set of 21 elections. Unavailable candidates will also be cut, albeit on a smaller scale. It is expected to remain well motivated so that candidate validators are willing to ensure quality and help secure the FSC In extreme cases, if a majority of the active 21 validators are attacked and taken offline, in the genesis block, the team set A node to ensure the normal operation of the public chain. The FON Smart Chain also supports EVM-compatible smart contracts and protocols. Cross-chain transfers and other communications are possible thanks to native support for interoperability. * **Self-sovereign blockchain：**Safety and security are provided through elected validators. * **EVM-comp**Support for all existing Ethereum tools plus faster finality and cheaper transactions * **Interoperable:** Comes with efficient native dual-chain communication; optimized for high-performance dApps that require a fast and smooth user experience. * **Distributed on-chain governance：** Proof of Stake (APoS) brings decentralization and community participation. As a native token, FON will serve as gas for smart contract execution and as a token for staking. ### **Cross-chain and multi-chain ecosystem​** An important lesson to learn from historical data is that "one chain" cannot cover all angles. At its peak, FSC had more than 2 million daily active users (DAU), with a single GameFi reaching 1 million DAU. This creates significant challenges for the network itself and its supporting infrastructure such as RPC/API nodes. For dApps with massive user bases, multi-chain and cross-chain should be the solution. The FSC core team firmly believes in the future of partitioned chains and multi-chains as it can sustain the ever-increasing demand for decentralized computing power and storage. This is consistent with the multi-chain strategy in many other blockchains in the industry such as ETH2.0 as well as Polkadot, Cosmos and Avalanche. Cross-shard and cross-chain/multi-chain interoperability will be key topics in 2022. The FSC token and developer community are committed to realizing FSC's vision of operating at the crossroads of the decentralized blockchain future. Specifically, we aim to achieve this by implementing new technologies on FSC through the FON sidechain and the FSC Partition Chain (FPC) infrastructure layer. ### Resources[​](https://docs.bnbchain.org/docs/learn/intro#resources) [White Paper](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvwkHQs7yXQT7ciUhgLaf%2Fuploads%2FgLwrylZIS4Cqh1iN3FYC%2FFON%20White%20Paper.pdf?alt=media\&token=720b884d-81ff-425a-a923-fc1dd0d1c0be) # Tutorial In this section, we provide a tutorial on the use of different components of the FON Smart Chain. **validator** * [How to build a validator on FSC](/develop/validator) Tutorial #### Full node * [How to run a full node on FSC ](/develop/validator/run)Tutorial #### Cross-chain bridge * [How to use the FON smart chain for cross-chain ](/bridgewallet/bridge)Tutorial #### Wallet * [How to Link FONChain with Wallet](/bridgewallet/wallet) Tutorial * [How to link FONChain through a third party](/bridgewallet/wallettutorial) Tutorial # Security Audit Report
## Beosin audit report Beosin's audit report on FON Smart Chain，[**View Audit Report**](https://beosin.com/audits/FON-Smart-Chain_202209291625.pdf) {% embed url="" %} # Social And Media Here you can find a list of FONChain official social media channels and communities. If English isn't your first language, we also have many non-English communities where you can join us! ### Follow us 𝕏 *** #### 💬 Telegram #### **Official Telegram Group:** * 📣 Announcement Channel (Global)**(** [**https://t.me/FonSmartChain**](https://t.me/FonSmartChain) **)** **English Group** ([ ](https://t.me/rosswapofficial) ) **Chinese Group** () # Cross-chain bridge The ability to transfer tokens across chains is a basic need. This allows users to move their funds from one blockchain network to another. Keeping in mind the importance of cross-chain support, multiple networks now have their own “bridges” to help facilitate money transfers. Below is a list of bridges and exchanges that support cross-chain transfers of FSC and other tokens. * HieSwap lightning cross-chain * SWFT cross-chain protocol List of cross-chain bridges that support BNB smart chain
type namewebsitetutorial
multi-chainHieSwap lightning cross-chainhttps://hieswap.comassociate
multi-chain tokenSWFThttps://www.allchainbridge.comassociate
# Wallet ### What is a wallet? A crypto wallet is a device or program used to transfer and store cryptocurrency. Crypto wallets can be of different types such as paper wallets, hardware wallets, and software wallets. There are also smartphone mobile apps and computer programs that offer a user-friendly way to create and manage wallets. Along with cryptocurrencies, crypto wallets store a set of cryptographic keys used to send, receive, and track ownership of cryptocurrencies. A key pair is a cryptographically derived, securely generated private and public key. The private key and its corresponding public key together are called a key pair. A wallet contains a collection of one or more key pairs and provides some methods for interacting with them. The security of any crypto wallet depends on how the private keys are stored. The public key is known as the receiving address of the wallet or simply the address. Wallet addresses can be freely shared and displayed. When another party wants to send a certain amount of cryptocurrency to a wallet, they need to know the wallet’s receiving address. Depending on the blockchain implementation, the address can also be used to view certain information about the wallet, such as viewing the balance, but cannot change any information about the wallet or withdraw any native coins and tokens. In order to send cryptocurrency to another address or make any changes to the wallet, the private key is used to digitally sign the transaction. It is important to note that private keys should never be shared and should always be kept securely. If access is gained in any way to the private keys attached to the wallet, an attacker can extract all contained tokens. Additionally, if a wallet's private key is lost, any coins that have been sent to or stored in that wallet address will be permanently lost. Different wallet solutions provide different methods of securing key pairs, interacting with key pairs, and signing transactions to use/spend tokens. Some are easier to use than others, and some are more secure for storing and backing up private keys. FON Smart Chain supports a variety of wallets, giving users the right to choose the right wallet to meet the security and convenience they require. If you want to be able to receive FON and other supported tokens on the Binance Smart Chain blockchain, you will first need to create a wallet and configure key management. ### Supported wallets * List of wallets that support the FON chain
numberwallet namewebsiteWhether to include
1Avewallethttps://ave.ai/downloadyes
2Bitkeephttps://bitkeep.com/yes
3TokenPockethttps://www.tokenpocket.proquick collection
4MetaMaskhttps://metamask.io/custom add
5Math Wallethttps://mathwallet.org/en-us/custom add
# Key management This article is a guideline on client key management strategies for FON smart chain decentralized applications ### FON setting Web3 web3.js is a JavaScript library that allows our client applications to talk to the blockchain. We configure web3 to communicate via Metamask. web3.js doctor [here](https://web3js.readthedocs.io/en/v1.2.2/getting-started.html#adding-web3-js) ### Connect to the FSC network ``` // mainnet const web3 = new Web3('https://fsc-dataseed1.fonscan.io:443'); ``` ### Set up account If the installation and instantiation of web3 was successful, the following should successfully return a random account: ``` const account = web3.eth.accounts.create(); ``` ### Recover account If you backed up your account private key, you can use it to restore your account. ``` const account = web3.eth.accounts.privateKeyToAccount("$private-key") ``` ### Complete example ``` const Web3 = require('web3'); async function main() { const web3 = new Web3('https://fsc-dataseed1.fonscan.io:443'); const loader = setupLoader({ provider: web3 }).web3; const account = web3.eth.accounts.create(); console.log(account); } ``` # Third-Party Wallet Tutorial The FON smart chain provides a wide range of third-party wallet support, which can be used to send/receive/purchase/exchange. Below we have provided a list of the most popular wallets. If the wallet has not officially included the FON smart chain, it supports customization, and can also be customized to add network parameters of the FON smart chain Fill in some basic network information of FON Chain, please fill in and check whether it is correct ``` Network name：FON Chain RPC URL：The current official RPC https://fsc-dataseed1.fonscan.io https://fsc-dataseed2.fonscan.io Chain ID：201022 Currency symbol：FON Blockchain explorer：https://fonscan.io ``` | wallet | tutorial link | | ---------- | ----------------------------------------------------------------------- | | Metamask | [Use FON Chain in Metamask](/bridgewallet/wallettutorial/metamask) | | Ave.ai | [Using FON Chain on Ave.ai](/bridgewallet/wallettutorial/ave.ai) | | Bitkeep | [Using FON Chain in Bitkeep](/bridgewallet/wallettutorial/bitkeep) | | TokenPocet | [Use FON Chain in TokenPocet](/bridgewallet/wallettutorial/tokenpocket) | # Metamask ## 1. Step 1 (Open the official website) Use Google Chrome to enter MetaMask official website
## 2. Step 2 (add plugin) Add through Google, install the "MetaMas" plug-in, click Add to Chrome
## 3. Step 3 (Create wallet) After installing the "MetaMas" plug-in, choose the way you want to import The latest version of MetaMas import only supports mnemonic words, please develop the habit of saving mnemonic words.
## 4. Step 4 (add network) After the import or creation is complete, officially enter the "MetaMas" wallet, select Add Network, and add the basic information of the mainnet
## 5. Step five (manually added) Manually add mainnet network information, as well as RPC and browser related information
## 6. Step 6 (Network parameters) ``` Network name: FON Chain RPC URL: the current official public RPC https://fsc-dataseed1.fonscan.io https://fsc-dataseed2.fonscan.io Chain ID: 201022 Currency symbol: FON Browser URL: https://fonscan.io ```
## 7. Step 7 (Complete the operation) Adding the above completes the use of adding the FON Chain network through "MetaMas"
{% hint style="danger" %} Kind tips: Please be sure to keep your mnemonic or private key in a safe place to avoid loss of assets. {% endhint %} # TokenPocket ## How to add FON Smart Chain in TokenPocket? 1、Open TokenPocket, click Add Wallet in the top right corner and click 【Add Custom Network】.
2\. Open the custom network interface, and click 【Easy Add】 in the upper right corner, TokenPocket will list the popular public chains, and you can easily search for the public chains you need to add through this entrance. Fill in 【fon】 in the search bar, and you can see the search results below, click it and be ready to add FON Smart Chain.
3\. Double-check the information and click “Save” in the right corner to add it successfully. Go back to the “Select Network” interface and pull down to the bottom to see the FON Mainnet.
4\. Click on the FON Mainnet, and you can choose “Create” or “Import” to use the FON wallet.
5、After adding the FON Smart Chain, click 【Details】, and select 【Wallet Sync】to select the wallet you want to sync.
# Bitkeep Using FON Chain through Bitkeep Wallet 1. Download the [Bitkeep wallet through the Bitekkep official website](https://bitkeep.com/), and enter the Bitkeep App after the download is complete
2. After entering the Bitkkep App, click to create a wallet, or import a wallet to create a new wallet, click to backup
3. Back up your mnemonic, please be sure to copy the mnemonic in a safe environment for verification
4. After creating a wallet, click All Networks to switch to the FSC network
5. Because Bitkkep supports multiple chains, you can quickly add them by searching for FSC After adding, click the + icon to add assets
6. By selecting the assets to be added, you can also search through the contract address Return to the wallet and display the assets you added So far, you have completed the creation of the FSC wallet through Bitkeep
# Ave.ai Using FON Chain through Ave.ai Wallet 1. Download the Ave.ai wallet through the Ave.ai official website, and enter the Ave.ai App after the download is complete
2. After entering the Ave.ai App, click Wallet, connect to the wallet and create it
3. According to your own usage, choose to create, or import through the private key Currently Ave.ai, the current version supports, create, import, and observe wallet functions
4. Set the wallet name, set the password, and click Confirm. Please be sure to copy the mnemonic in a safe environment for verification
5. After creating the wallet, click to switch the FSC network, click to select FSC
6. Click the + icon to select the assets on FSC, and the popular single currency and assets will be loaded automatically
7. Switch to all FSC transaction lists, click on the market, and select FSC
# Consensus engine Although Proof-of-Work (PoW) has been recognized as a practical mechanism for implementing decentralized networks, it is not environmentally friendly and requires a large number of participants to maintain security. Ethereum and some other blockchain networks like MATIC Bor, TOMOChain, GoChain, xDAI do use Proof of Authority (PoA) or its variants in different scenarios, including testnets and mainnets. PoA provides some defense against 51% attacks, increased efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). It can be an easy choice as a basis for selection. At the same time, the most criticized part of the PoA protocol is that it is not as decentralized as PoW, because the validators, the nodes that take turns to generate blocks, have all permissions and are vulnerable to corruption and security attacks. Other blockchains, such as EOS and Lisk, have introduced different types of Delegated Proof-of-Stake (DPoS) to allow token holders to vote and elect validator sets. It increases decentralization and facilitates community governance. FSC hereby proposes to combine DPoS and PoA for consensus, so that: 1. Validator sets are elected in and out based on stake-based governance 2. Validators take turns producing blocks in PoA, similar to Ethereum's Clique consensus design 3. Blocks are produced by a limited set of validators **FSC's consensus protocol achieves the following goals:** 1. The block time is short, 3 seconds on the mainnet. 2. Confirming the finality of a transaction takes a finite amount of time, about 45 seconds on mainnet. 3. There is no inflation in the native token FON, and block rewards are collected from transaction fees and paid in FON. 4. It is 100% compatible with the Ethereum system. 5. It allows modern proof-of-stake blockchain network governance. ### Validator Quorum During the genesis phase, some trusted nodes will operate as the initial set of validators. After the block starts, anyone can compete to join as a candidate to elect a validator. The staking state determines the top 21 most staked nodes to be the next validator set, and such an election will repeat every 3 hours. FON is the token used to stake FSC. In order to maintain compatibility with Ethereum and be able to upgrade to consensus protocols to be developed in the future, these rules of FSC are all written into the Genesis Contract. There is a dedicated staking module for Dapps on FSC. ### Paglia The implementation of the consensus engine is named Parlia, similar to clique. This document will focus more on differences and ignore common details. #### Light client security Validator set changes happen at (epoch+N/2) blocks. (N is the size of the validator set before the epoch block). Considering the safety of light clients, we delay N/2 blocks for validatorSet changes. Every epoch block, the validator will query the validator set from the contract and fill it into the extra\_data field of the block header. Full nodes will validate it against the set of validators in the contract. The light client will use it as a validatorSet for the next epoch block, however, it cannot verify it according to the contract, it must trust the signer of the epoch block. If the signer of the epoch block writes the wrong extra\_data, light clients may go to the wrong chain. If we delay N/2 blocks for the validatorSet to change, the wrong epoch block will not get other N/2 subsequent blocks signed by other validators, so light clients will not be vulnerable to this attack. #### System transaction The consensus engine may call the system contract, and such transactions are called system transactions. System transactions are signed by validators who produce blocks. For the witness node, a system transaction (without signature) will be generated according to its internal logic, compared with the system transaction in the block, and then applied. #### Forced retreat In the Clique consensus protocol, out-of-order validators must wait for a random amount of time before sealing a block. It is implemented in the client node software and assumes that validators will be running the canonical version. However, given that validators are economically incentivized to seal blocks as quickly as possible, validators may run modified versions of node software to ignore this delay. To prevent validators from hastily blocking blocks, each validator whose turn it is is given a specified time period to block. Any block produced by a validator with an earlier block time will be discarded by other witness nodes. #### Pass interim review If a transaction updating a validator is sent to the FSC during an epoch, then validators may review the transaction and not change the validator set for that epoch. While a transaction cannot be reviewed forever without the help of n/2 other validators, it can extend the time of the current validator set and earn some rewards. In general, the probability of this scheme can be increased by colluding with other validators. This is a relatively benign problem, a block is maybe about 3 seconds, and an epoch is 200 blocks, or 20 minutes, so validators can only extend it by another 10 minutes. ### Security and Finality Assuming more than ½ \* N+1 validators are honest, PoA-based networks can generally work securely and correctly. However, under certain circumstances, a certain number of Byzantine validators may still manage to attack the network, for example through cloning attacks. To be as secure as FC, FSC users are encouraged to wait until they have received blocks sealed by more than ⅔\*N+1 different validators. In this way, FSC can be trusted with a similar level of security as FC, and can tolerate fewer than ⅓ \* N Byzantine validators. With 50 validators, if the block time is 3 seconds, then ⅔ \* N + 1 different validator stamps will require (⅔ \* 21 + 1) \* time period 3 = 45 seconds. Any critical application of the FSC will likely have to wait ⅔ \* N+1 for relatively safe finality. However, in addition to such arrangements, the FSC does introduce slashing logic to penalize Byzantine validators for double-signing or unavailability. This slashing logic will expose malicious validators in a very short time and make "cloning attacks" very difficult or extremely unhelpful to execute. With this enhancement, ½ \* N+1 or even fewer blocks are enough for most transactions to be confirmed. # RPC SON-RPC endpoint ### RPC access circuit ### FSC-Fonvity1 {% hint style="success" %} ; {% endhint %} ### FSC-Fonvity2 {% hint style="success" %} {% endhint %} ### FSC-Chain ID：201022 # FSC Browser The FON Smart Chain (FSC) browser is a graphical user interface designed to allow users to interact with the blockchain. Through this interface, users can browse the added block information on the blockchain, transactions on the blockchain, wallet balance, and FON information. FON Smart Chain (FSC) provides a browser for its mainnet. ### Mainnet explorer * FonScan1 - [https://fonscan.io](https://fonscan.io/) * FonScan2- # Run full node ### Full node function * Stores the full blockchain history on disk and can answer requests for data from the network. * Receive and validate new blocks and transactions. * Verify the status of each account. ### Support platform We currently support running full node Linux. ### Recommended requirements #### Full node * The VPS runs the latest version of Linux. * Important 1T GB free disk space, solid state drive (SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms. (NVMe SSD required if starting from snapshot/quick sync) * 8-core CPU and 16 GB of memory (RAM). * The recommended instance type is m5zn.3xlarge on AWS and c2-standard-16 on Google Cloud. * Broadband internet connection with upload/download speed of 5 megabytes per second #### Validator * The VPS runs the latest version of Linux. * Important 1T GB free disk space, solid state drive (SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms * 8-core CPU and 16 GB of memory (RAM) * We recommend the m5zn.3xlarge instance type on AWS, or c2-standard-16 on Google Cloud. * Broadband Internet connection with upload/download speed of 10 megabytes per second #### Synchronous mode * Quick sync Default sync mode. Synchronizes a fast-syncing full node by downloading the entire state database, first requesting headers, and then filling in block bodies and receipts. Once the fast sync reaches the best block of the FON smart chain network, it will switch to full sync mode. * Full sync Synchronizes a full node from genesis, validating all blocks and executing all transactions. This mode is a bit slower than Quick Sync, but more secure. ## Run full node #### Sync from snapshot (recommended) [**Download the**](https://github.com/FONSmartChain/FSC) prebuilt binaries from the releases page or follow the instructions below ### 1.Download binaries ``` wget https://github.com/FONSmartChain/FSC/raw/master/geth sudo chmod +x geth ``` ### 2.Download the genesis block ``` wget https://github.com/FONSmartChain/FSC/raw/master/genesis.json ``` ### 3.Initialize the genesis block ``` ./geth init --datadir data genesis.json ``` ### 4.Download static node list ``` wget https://github.com/FONSmartChain/FSC/raw/master/static-nodes.json -O data/geth/static-nodes.json ``` ### 5.Start node ``` ./geth --datadir data --networkid 201022 \ --http --http.port 20102 --http.addr 0.0.0.0 --http.api "web3,eth,txpool,net" \ --port 20103 ``` # Validator ## Overview FON Smart Chain is an innovative solution, FON Smart Chain relies on a system of 99 validators with Proof of Stake (APoS) consensus that supports short block times and low fees. The validator candidate with the most stake will become a validator and produce blocks. Double-signature detection and other slashing logic guarantee security, stability, and chain finality. In addition to the 21 active verifiers, FSC will also introduce more verifiers, for example, more than 21 inactive verifiers will be added to the verifier set as backups, and these verifiers will be called "candidates". Unavailable candidates will also be cut, but on a smaller scale. Good incentives are expected to remain so that candidate validators are willing to ensure quality and help secure FSC. In the extreme case, if a majority of the 21 active validators are attacked and go offline, validator candidates can report stale blockages to the beacon chain, restore it and eventually propose to re-elect the active validator set. ### What is a validator? FON Smart Chain relies on a set of validators who are responsible for submitting new blocks in the blockchain. These validators participate in the consensus protocol by signing blocks containing cryptographic signatures signed by each validator's private key. The validator set is determined by the pledge module built on the FON smart chain, and the election rankings are refreshed every 3 hours to elect 21 valid validators. # Create a validator ### Create a mining account You need to first create an account representing the key pair. Create a new account and set a password for the account with the following command: ``` geth account new --datadir ./data ``` This command will return the public address and the path to the private key. A backup of the key file is necessary! If you already have an account, use the seed phrase to restore it: ``` geth account import --datadir ./data ``` #### Become a validator candidate You need to use the [FSC Validator](https://fscnode.fonscan.io/#/) contract to create a validator, To create a verifier, you need to pledge 9999 FON After the creation is complete, you need the creator's address, vote for yourself first, and let yourself enter the 99th place In the validator campaign, the campaign ranking is refreshed every 3 hours, so as to compete for the qualification of the block producer. # Run validator ### Validator hardware requirements * A VPS running the latest version of Mac OS X or Linux. * Important 2T GB free disk space, Solid State Drive (SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms (NVMe SSD required if booting with snapshot/quick sync) * 16-core CPU and 64 GB of memory (RAM) * We recommend using the m5zn.3xlarge instance type on AWS, or c2-standard-16 on Google Cloud. * Broadband Internet connection with upload/download speed of 10 megabytes per second ### Set up a validator #### 1.Synchronize block information Follow the instructions here to set up a full node. #### Start the validator ！！！Warning Please do not expose your RPC endpoints to the public network. ``` ## generate the consensus key and input the password echo {your-password to the mining account} > password.txt geth --datadir data \ --networkid 201022 \ --nodiscover \ --syncmode full \ --password password.txt \ --allow-insecure-unlock \ --unlock {the address of your mining account} \ --miner.gasprice 150000000000 \ --mine \ --miner.threads 1 \ --miner.gaslimit 80000000 ``` #### Stop verification You can stop mining new blocks by sending the command in the geth console Connect to your validator using geth attach ipc:path/to/geth.ipc ``` miner.stop() ``` To resume verification, ``` miner.start() ``` # Validate contracts at FONSCAN **Step 1:** Deploy your contract on the FON smart chain **Step 2:** Go to [FON SCAN](https://fonscan.com/verified-contracts) Click "Verify and Publish"
**Step Three:** Fill in the correct information for your contract
* Contract address * The compiler type you choose in Remix or another compiler * Select an open source license type **Step 4:** Enter the Solidity contract code If enabled, you need to select "Yes" for optimization. Constructor parameters are optional. If your contract has it, you can go to [**this page**](https://abi.hashex.org/) Generate encoded ABI json. ! ! ! information ``` The default FRC20 contract template does not have a constructor method ``` Click Verify and Publish to complete the process. Now you are ready to go! # Logos
**Download Brand Package：** {% file src="/files/yCRizwbsNxHCnxwCFoKR" %} # RPC API Endpoints This API is provided for developers transitioning applications from Etherscan to BlockScout and applications requiring general API and data support. It supports GET and POST requests. {% hint style="info" %} URLs vary by instance. With typical installations, access the API by adding `/ap`i to the end of the url. For example with the Goerli instance. * URL: * API URL: An example query includes a module and action(s)/parameters. For example: \ [https://fonscan.io/api?module=**account**\&action=**listaccounts**\&page=2\&offset=5](https://fonscan.io/api?module=account\&action=listaccounts\&page=2\&offset=5) {% endhint %} The following modules are supported. Click through to see specific endpoints and parameters.
Account?module=account
Logs?module=logs
Token?module=token
Stats?module=stats
Block?module=block
Contract?module=contract
Transaction?module=transaction
# Account ?module=account {% hint style="success" %} ### `https://fonscan.io/api?module=account` {% endhint %} ## Return balance from a provided block `eth_get_balance` Mimics Ethereum JSON RPC's eth\_getBalance **Example:** ``` https://fonscan.io/api ?module=account &action=eth_get_balance &address={addressHash} ``` {% tabs %} {% tab title="Request params" %}
Parameter Description
addressstring containing the address hash.
blockoptional. Block number as a string, or latest, earliest or pending

Latest is the latest balance in a consensus block. Earliest is the first recorded balance for the address. Pending is the latest balance in a consensus or nonconsensus block.
{% endtab %} {% tab title="Example Result" %} ``` { "id": 1, "jsonrpc": "2.0", "result": "0x0234c8a3397aab58" } ``` {% endtab %} {% endtabs %} ## Get the native token balance for an address `balance` Many chains use their own native tokens. On Ethereum, this will return the result in "Ether", on Gnosis it will be "xDai", etc. Results are returned in wei. **Example:** ``` https://fonscan.io/api ?module=account &action=balance &address={addressHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ------------------------------------- | | **address** | `string` containing the address hash. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": "663046792267785498951364", "status": "1" } ``` {% endtab %} {% endtabs %} {% hint style="warning" %} Also available through a GraphQL `address` query. {% endhint %} {% hint style="warning" %} If the balance hasn't been updated recently, the node is double-checked to fetch the absolute latest balance. This will not be reflected in the current request, but once it is updated, subsequent requests will show the updated balance. If you want to know if there is a check for another balance, use the `balancemult`i action. That contains a property called `stale` that will let you know to recheck that balance in the near future. {% endhint %} ## Get balance for multiple addresses `balancemulti` **Example:** ``` https://fonscan.io/api ?module=account &action=balancemulti &address={addressHash1,addressHash2,addressHash3} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ---------------------------------------------------------------------------- | | **address** | `string` containing the address hash, comma separated. **Max 20 addresses.** | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "account": "0xddbd2b932c763ba5b1b7ae3b362eac3e8d40121a", "balance": "40807168566070000000000", "stale": true }, { "account": "0x63a9975ba31b0b9626b34300f7f627147df1f526", "balance": "332567136222827062478", "stale": false }, { "account": "0x198ef1ec325a96cc354c7266a038be8b5c558f67", "balance": "185178830000000000", "stale": false } ], "status": "1" } ``` {% endtab %} {% endtabs %} {% hint style="warning" %} Also available through a GraphQL 'addresses' query {% endhint %} {% hint style="warning" %} If the balance hasn't been updated in a long time, the node is double checked to fetch the absolute latest balance. This is not reflected in the current request, but once it is updated, subsequent requests will show the updated balance. The **`stale`** attribute will be set to **`true`** if a new balance is being fetched. {% endhint %} ## Get pending transactions by address `pendingtxlist` **Example:** ``` https://fonscan.io/api ?module=account &action=pendingtxlist &address={addressHash} &page=1 &offset=5 ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **address** | `string` containing the address hash. | | page | optional `integer` representing the page number used for pagination. 'offset' must also be provided. | | offset | optional `integer` representing number of transactions returned per page. `page` must also be provided. | | {% endtab %} | | {% tab title="Example Result" %} ``` "message": "OK", "result": [ { "contractAddress": "", "cumulativeGasUsed": "122207", "from": "0x3fb1cd2cd96c6d5c0b5eb3322d807b34482481d4", "gas": "122261", "gasPrice": "50000000000", "gasUsed": "122207", "hash": "0x98beb27135aa0a25650557005ad962919d6a278c4b3dde7f4f6a3a1e65aa746c", "input": "0xf00d4b5d000000000000000000000000036c8cecce8d8bbf0831d840d7f29c9e3ddefa63000000000000000000000000c5a96db085dda36ffbe390f455315d30d6d3dc52", "nonce": "0", "to": "0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae", "value": "0" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get transactions by address `txlist` Maximum of 10,000 transactions. Also available through a GraphQL 'address' query. For faster results, specify a smaller block range to search using the start\_block and end\_block parameters **Example:** ``` https://fonscan.io/api ?module=account &action=txlist &address={addressHash} &startblock=555555 &endblock=666666 &page=1 &offset=5 &sort=asc ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **address** | `string` containing the address hash. | | sort | optional sorting preference, `asc` for ascending and `desc` for descending. Descending is default. | | start\_block | optional `integer` block number to start transaction search | | end\_block | optional`integer` block number to stop transaction search. | | page | optional `integer` representing the page number used for pagination. `offset` must also be provided. | | offset | optional `integer` representing number of transactions returned per page. `page` must also be provided. | | filter\_by | optional string representing the field to filter by. Values include `to` and `from`. If none provided returns transactions that match to, from, or contract address. | | start\_timestamp | optional starting block unix timestamp. | | end\_timestamp | optional ending block unix timestamp. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "blockHash": "0x373d339e45a701447367d7b9c7cef84aab79c2b2714271b908cda0ab3ad0849b", "blockNumber": "65204", "confirmations": "5994246", "contractAddress": "", "cumulativeGasUsed": "122207", "from": "0x3fb1cd2cd96c6d5c0b5eb3322d807b34482481d4", "gas": "122261", "gasPrice": "50000000000", "gasUsed": "122207", "hash": "0x98beb27135aa0a25650557005ad962919d6a278c4b3dde7f4f6a3a1e65aa746c", "input": "0xf00d4b5d000000000000000000000000036c8cecce8d8bbf0831d840d7f29c9e3ddefa63000000000000000000000000c5a96db085dda36ffbe390f455315d30d6d3dc52", "isError": "0", "nonce": "0", "timeStamp": "1439232889", "to": "0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae", "transactionIndex": "0", "txreceipt_status": "1", "value": "0" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get internal transactions by transaction or address hash `txlistinternal` Up to a maximum of 10,000 internal transactions. Also available through a GraphQL 'transaction' query. For faster results, specify a smaller block range to search using the start\_block and end\_block parameters. **Example:** ``` https://fonscan.io/api ?module=account &action=txlistinternal &txhash={transactionHash} &startblock=555555 &endblock=666666 &page=1 &offset=5 &sort=asc ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **txhash** | `string` representing the transaction hash to check for internal transactions | | address | optional `string` containing the address hash. | | sort | optional sorting preference, `asc` for ascending and `desc` for descending. Descending is default. **Only available if 'address' is provided.** | | start\_block | optional `integer` block number to start transaction search. **Only available if 'address' is provided.** | | end\_block | optional`integer` block number to stop transaction search. **Only available if 'address' is provided.** | | page | optional `integer` representing the page number used for pagination. `offset` must also be provided. **Only available if 'address' is provided.** | | offset | optional `integer` representing number of transactions returned per page. `page` must also be provided. **Only available if 'address' is provided.** | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "blockNumber": "6153702", "callType": "delegatecall", "contractAddress": "0x883103875d905c11f9ac7dacbfc16deb39655361", "errCode": "", "from": "0x2ca1e3f250f56f1761b9a52bc42db53986085eff", "gas": "814937", "gasUsed": "536262", "index": "0", "input": "", "isError": "0", "timeStamp": "1534362606", "to": "", "transactionHash": "0xd65b788c610949704a5f9aac2228c7c777434dfe11c863a12306f57fcbd8cdbb", "type": "call", "value": "5488334153118633" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get token transfer events by address `tokentx` Up to a maximum of 10,000 token transfer events. Also available through the GraphQL `token_transfers` query. **Example:** ``` https://fonscan.io/api ?module=account &action=tokentx &address={addressHash} &page=1 &offset=10 &sort=asc ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **address** | `string` containing the address hash. | | contract address | optional `string` with the token contract address to identify a contract. | | sort | optional sorting preference, `asc` for ascending and `desc` for descending. Descending is default. | | start\_block | optional `integer` block number to start transaction search | | end\_block | optional`integer` block number to stop transaction search. | | page | optional `integer` representing the page number used for pagination. `offset` must also be provided. | | offset | optional `integer` representing number of transactions returned per page. `page` must also be provided. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "blockHash": "0x6169c5dc05d0051564ba3eae8ebfbdefda640c5f5ffc095846b8aed0b44f64ea", "blockNumber": "5997843", "confirmations": "199384", "contractAddress": "0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2", "cumulativeGasUsed": "1043649", "from": "0x4e83362442b8d1bec281594cea3050c8eb01311c", "gas": "44758", "gasPrice": "7000000000", "gasUsed": "37298", "hash": "0xd65b788c610949704a5f9aac2228c7c777434dfe11c863a12306f57fcbd8cdbb", "input": "0xa9059cbb00000000000000000000000021e21ba085289f81a86921de890eed30f1ad23750000000000000000000000000000000000000000000000008ac7230489e80000", "logIndex": "0", "nonce": "765", "timeStamp": "1532086946", "to": "0x21e21ba085289f81a86921de890eed30f1ad2375", "tokenDecimal": "18", "tokenName": "Maker", "tokenSymbol": "MKR", "transactionIndex": "27", "value": "10000000000000000000" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get token account balance for token contract address `tokenbalance` **Example:** ``` https://fonscan.io/api ?module=account &action=tokenbalance &contractaddress={contractAddressHash} &address={addressHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | -------------------- | --------------------------------------------------------------------- | | **contract address** | `string` containing the contract address hash. | | **address** | `string` containing the account address hash to retrieve balance for. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": "135499", "status": "1" } ``` {% endtab %} {% endtabs %} ## Get list of tokens owned by address `tokenlist` **Example:** ``` https://fonscan.io/api ?module=account &action=tokenlist &address={addressHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | --------------------------------------------- | | **address** | `string` containing the account address hash. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "balance": "135499", "contractAddress": "0x0000000000000000000000000000000000000000", "decimals": "18", "name": "Example Token", "symbol": "ET", "type": "ERC-20" }, { "balance": "1", "contractAddress": "0x0000000000000000000000000000000000000001", "decimals": "18", "name": "Example ERC-721 Token", "symbol": "ET7", "type": "ERC-721" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get list of blocks mined by address `getminedblocks` **Example:** ``` https://fonscan.io/api ?module=account &action=getminedblocks &address={addressHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | -------------------- | --------------------------------------------------------------------- | | **contract address** | `string` containing the contract address hash. | | **address** | `string` containing the account address hash to retrieve balance for. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": "135499", "status": "1" } ``` {% endtab %} {% endtabs %} ## Get a list of accounts and their balances `listaccounts` Lists accounts and native balances, sorted ascending by the time they were first seen by the explorer. **Example:** ``` https://fonscan.io/api ?module=account &action=listaccounts &address={addressHash} &page=1 &offset=3 ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | page | optional `integer` representing the page number used for pagination. 'offset' must also be provided. | | offset | optional `integer` representing number of transactions returned per page. `page` must also be provided. | {% hint style="warning" %} If the balance hasn't been updated in a long time, the node is double checked to fetch the absolute latest balance. This is not reflected in the current request, but once it is updated, subsequent requests will show the updated balance. The **`stale`** attribute will be set to **`true`** if a new balance is being fetched. {% endhint %} {% endtab %} {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "address": "0x3870c57fbf1d7e49b154269331c7bc66c64d8857", "balance": "3790064387342000000", "stale": false }, { "address": "0x497d69ae30d7cca0aa84d647c6d85a59a82c16ef", "balance": "2047176464264000000", "stale": false }, { "address": "0x9233042b8e9e03d5dc6454bbbe5aee83818ff103", "balance": "444111960222208758647", "stale": false } ], "status": "1" } ``` {% endtab %} {% endtabs %} # Block ?module=block {% hint style="success" %} ### `https://fonscan.io/api?module=block` {% endhint %} ## Get block reward by block number `getblockreward` Returns the block reward and 'uncle' block rewards when applicable. **Example:** ``` https://fonscan.io/api ?module=block &action=getblockreward &blockno={blockNumber} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | --------------------------------------------------------------- | | blockno | `integer` block number to check block rewards for eg. `2165403` | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "blockMiner": "0x13a06d3dfe21e0db5c016c03ea7d2509f7f8d1e3", "blockNumber": "2165403", "blockReward": "5314181600000000000", "timeStamp": "1472533979", "uncleInclusionReward": null, "uncles": null }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Get block number by time stamp `getblocknobytime` Returns the block number created closest to a provided timestamp. **Example:** ``` https://fonscan.io/api ?module=block &action=getblocknobytime ×tamp={blockTimestamp} &closest={before/after} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | --------- | -------------------------------------------------------------------- | | timestamp | `integer` representing the Unix timestamp in seconds. | | closest | closest block to the provided timestamp, either `before` or `after`. | Note: [How to convert date/time to a Unix timestamp](https://www.unixtimestamp.com/). {% endtab %} {% tab title="Example Result" %} ``` { "message": "OK", "result": { "blockNumber": "2165403" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Get the latest block number `eth_block_number` Mimics Ethereum JSON RPC's eth\_blockNumber. **Example:** ``` https://fonscan.io/api ?module=block &action=eth_block_number ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | --------- | ------------------------------------------------------------------------------------------------------------------- | | id | optional nonnegative integer that represents the json rpc request id. | More on [json rpc request id](https://www.jsonrpc.org/specification). {% endtab %} {% tab title="Example Result" %} ``` { "jsonrpc": "2.0", "result": "0x103538a", "id": 1 } ``` {% endtab %} {% endtabs %} # Contract ?module=contract {% hint style="success" %} ### `https://fonscan.io/api?module=contract` {% endhint %} ## Get a list of contracts `listcontracts` List sorted in ascending order based on the time a contact was first indexed by the explorer. With filters \`not\_decompiled\`(\`4\`) or \`not\_verified(4)\` the results will not be sorted for performance reasons. **Example:** ``` https://fonscan.io/api ?module=contract &action=listcontracts ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | page | optional nonnegative `integer` representing the page number used for pagination. 'offset' must also be provided. | | offset | optional nonnegative `integer` representing the max number of records to return when paginating. 'page' must also be provided. | | filter | optional string `verified`\|`decompiled`\|`unverified`\|`not_decompiled`\|`empty`, or `1`\|`2`\|`3`\|`4`\|`5` respectively. Returns contracts with the requested status. | | not\_decompiled\_with\_version | optional `string` ensures none of the returned contracts were decompiled with the provided version. Ignored unless filtering for `decompiled` contracts. | | verified\_at\_start\_timestamp | optional `unix timestamp` Represents the starting timestamp for verified contracts. Only used with `verified` filter. | | verified\_at\_end\_timestamp | optional `unix timestamp` Represents the ending timestamp for verified contracts. Only used with `verified` filter. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "ABI": "[{\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event2\"\n}, {\n\"type\":\"function\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\"}],\n\"name\":\"foo\",\n\"outputs\": []\n}]\n", "CompilerVersion": "v0.2.1-2016-01-30-91a6b35", "ContractName": "Test", "OptimizationUsed": "1", "SourceCode": "pragma solidity >0.4.24;\n\ncontract Test {\nconstructor() public { b = hex\"12345678901234567890123456789012\"; }\nevent Event(uint indexed a, bytes32 b);\nevent Event2(uint indexed a, bytes32 b);\nfunction foo(uint a) public { emit Event(a, b); }\nbytes32 b;\n}\n" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get ABI for a verified contract `getabi` Also available through a GraphQL `addresses` query. **Example:** ``` https://fonscan.io/api ?module=contract &action=getabi &address={addressHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ------------------------------------- | | **address** | `string` containing the address hash. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": "[{\"constant\":false,\"inputs\":[{\"name\":\"voucher_token\",\"type\":\"bytes32\"}],\"name\":\"burn\",\"outputs\":[{\"name\":\"success\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"constant\":true,\"inputs\":[{\"name\":\"voucher_token\",\"type\":\"bytes32\"}],\"name\":\"is_expired\",\"outputs\":[{\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"view\",\"type\":\"function\"},{\"constant\":false,\"inputs\":[{\"name\":\"voucher_token\",\"type\":\"bytes32\"}],\"name\":\"is_burnt\",\"outputs\":[{\"name\":\"\",\"type\":\"bool\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"function\"},{\"inputs\":[{\"name\":\"voucher_token\",\"type\":\"bytes32\"},{\"name\":\"_lifetime\",\"type\":\"uint256\"}],\"payable\":false,\"stateMutability\":\"nonpayable\",\"type\":\"constructor\"}]", "status": "1" } ``` {% endtab %} {% endtabs %} ## Get contract source code for a verified contract `getsourcecode` Also available through a GraphQL `addresses` query. **Example:** ``` https://fonscan.io/api ?module=contract &action=getsourcecode &address={addressHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ------------------------------------- | | **address** | `string` containing the address hash. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "ABI": "[{\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event2\"\n}, {\n\"type\":\"function\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\"}],\n\"name\":\"foo\",\n\"outputs\": []\n}]\n", "CompilerVersion": "v0.2.1-2016-01-30-91a6b35", "ContractName": "Test", "FileName": "{sourcify path or empty}", "ImplementationAddress": "0x000000000000000000000000000000000000000e", "IsProxy": "true", "OptimizationUsed": "1", "SourceCode": "pragma solidity >0.4.24;\n\ncontract Test {\nconstructor() public { b = hex\"12345678901234567890123456789012\"; }\nevent Event(uint indexed a, bytes32 b);\nevent Event2(uint indexed a, bytes32 b);\nfunction foo(uint a) public { emit Event(a, b); }\nbytes32 b;\n}\n" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Verify a contract with its source code and contract creation information `verify` **Example:** ``` https://fonscan.io/api ?module=contract &action=verify &addressHash={addressHash} &name={name} &compilerVersion={compilerVersion} &optimization={false} &contractSourceCode={contractSourceCode} ``` **Curl Post Example** {% code overflow="wrap" %} ``` curl -d '{"addressHash":"0xc63BB6555C90846afACaC08A0F0Aa5caFCB382a1","compilerVersion":"v0.5.4+commit.9549d8ff", "contractSourceCode":"pragma solidity ^0.5.4; contract Test { }","name":"Test","optimization":false}' -H "Content-Type: application/json" -X POST "https://blockscout.com/poa/sokol/api?module=contract&action=verify" ``` {% endcode %} {% hint style="warning" %} On successful submission you will receive a guid as a receipt. Use this with [`checkverifystatus`](#return-status-of-a-verification-attempt)`to view verification status.` {% endhint %} {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | **addressHash** | `string` containing the address hash of the contract. | | **name** | `string` containing the name of the contract. | | **compilerVersion** | `string` containing the compiler version for the contract. | | **optimization** | `enum` whether or not compiler optimizations were enabled `0`=false, `1`=true | | **contractSourceCode** | `string` containing the source code of the contract. | | constructorArguments | optional `string` constructor argument data provided. | | autodetectConstructorArguments | optional `boolean` whether or not automatically detect constructor argument. | | evmVersion | optional EVM version for the contract. | | optimizationRuns | optional number of optimization runs used during compilation | | library1Name | optional `string` name of the first library used. | | library1Address | optional `string` address of the first library used. | | library2Name | optional `string` name of the second library used. | | library2Address | optional `string` address of the second library used. | | library3Name | optional `string` name of the third library used. | | library3Address | optional `string` address of the third library used. | | library4Name | optional `string` name of the fourth library used. | | library4Address | optional `string` address of the fourth library used. | | library5Name | optional `string` name of the fifth library used. | | library5Address | optional `string` address of the fifth library used. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "ABI": "[{\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event2\"\n}, {\n\"type\":\"function\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\"}],\n\"name\":\"foo\",\n\"outputs\": []\n}]\n", "CompilerVersion": "v0.2.1-2016-01-30-91a6b35", "ContractName": "Test", "ImplementationAddress": "0x000000000000000000000000000000000000000e", "IsProxy": "true", "OptimizationUsed": "1", "SourceCode": "pragma solidity >0.4.24;\n\ncontract Test {\nconstructor() public { b = hex\"12345678901234567890123456789012\"; }\nevent Event(uint indexed a, bytes32 b);\nevent Event2(uint indexed a, bytes32 b);\nfunction foo(uint a) public { emit Event(a, b); }\nbytes32 b;\n}\n" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Verify a contract through [Sourcify](https://sourcify.dev/) `verify_via_sourcify` 1. if a smart contract is already verified on Sourcify, it will automatically fetch the data from the [repo](https://repo.sourcify.dev/) 2. otherwise you need to upload source files and JSON metadata file(s). **Example:** ``` https://fonscan.io/api ?module=contract &action=verify_via_sourcify &addressHash={addressHash} ``` #### POST body example ``` --6e1e4c11657c62dc1e4349d024de9e28 Content-Disposition: form-data; name="addressHash" 0xb77b7443e0F32F1FEBf0BE0fBd7124D135d0a525 --6e1e4c11657c62dc1e4349d024de9e28 Content-Disposition: form-data; name="files[0]"; filename="contract.sol" Content-Type: application/json ...Source code... --6e1e4c11657c62dc1e4349d024de9e28 Content-Disposition: form-data; name="files[1]"; filename="metadata.json" Content-Type: application/json ...JSON metadata... --6e1e4c11657c62dc1e4349d024de9e28-- ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | --------------- | --------------------------------------- | | **addressHash** | `string` containing the address hash. | | files | `array` with sources and metadata files | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "ABI": "[{\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event2\"\n}, {\n\"type\":\"function\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\"}],\n\"name\":\"foo\",\n\"outputs\": []\n}]\n", "CompilerVersion": "v0.2.1-2016-01-30-91a6b35", "ContractName": "Test", "ImplementationAddress": "0x000000000000000000000000000000000000000e", "IsProxy": "true", "OptimizationUsed": "1", "SourceCode": "pragma solidity >0.4.24;\n\ncontract Test {\nconstructor() public { b = hex\"12345678901234567890123456789012\"; }\nevent Event(uint indexed a, bytes32 b);\nevent Event2(uint indexed a, bytes32 b);\nfunction foo(uint a) public { emit Event(a, b); }\nbytes32 b;\n}\n" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Verify a vyper contract with its source code and contract creation information `verify_vyper_contract` **Example** ``` https://fonscan.io/api ?module=contract &action=verify_vyper_contract &addressHash={addressHash} &name={name} &compilerVersion={compilerVersion} &contractSourceCode={contractSourceCode} ``` **curl POST example** {% code overflow="wrap" %} ``` curl --location --request POST 'http://localhost:4000/api?module=contract&action=verify_vyper_contract' --form 'contractSourceCode="SOURCE_CODE"' --form 'name="Vyper_contract"' --form 'addressHash="0xE60B1B8bD493569a3E945be50A6c89d29a560Fa1"' --form 'compilerVersion="v0.2.12"' ``` {% endcode %} {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ---------------------- | ---------------------------------------------------------- | | **addressHash** | `string` containing the address hash of the contract. | | **name** | `string` containing the name of the contract. | | **compilerVersion** | `string` containing the compiler version for the contract. | | **contractSourceCode** | `string` containing the source code of the contract. | | constructorArguments | `string` constructor argument data provided. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "ABI": "[{\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event2\"\n}, {\n\"type\":\"function\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\"}],\n\"name\":\"foo\",\n\"outputs\": []\n}]\n", "CompilerVersion": "v0.2.1-2016-01-30-91a6b35", "ContractName": "Test", "ImplementationAddress": "0x000000000000000000000000000000000000000e", "IsProxy": "true", "OptimizationUsed": "1", "SourceCode": "pragma solidity >0.4.24;\n\ncontract Test {\nconstructor() public { b = hex\"12345678901234567890123456789012\"; }\nevent Event(uint indexed a, bytes32 b);\nevent Event2(uint indexed a, bytes32 b);\nfunction foo(uint a) public { emit Event(a, b); }\nbytes32 b;\n}\n" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Verify a contract with Standard input JSON file `verifysourcecode` **Example** ``` https://fonscan.io/api ?module=contract &action=verifysourcecode &codeformat={solidity-standard-json-input} &contractaddress={contractaddress} &contractname={contractname} &compilerversion={compilerversion} &sourceCode={sourceCode} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **codeformat** | Format of sourceCode (currently only supports `solidity-standard-json-input`) | | **contractaddress** | `string` containing the address hash of the contract. | | **contractname** | `string` name of the contract. It an be an empty string(""), just the contract name("ContractName"), or a filename and contract name("contracts/contract\_1.sol:ContractName") | | **compilerversion** | `string` containing the compiler version for the contract. | | **sourceCode** | `string` standard input json | | constructorArguments | optional `string` constructor argument data provided. | | autodetectConstructorArguments | optional `boolean` whether or not automatically detect constructor argument. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": "b080b96bd06ad1c9341c2afb7e3730311388544961acde94", "status": "1" } ``` {% endtab %} {% endtabs %} ## Return status of a verification attempt `checkverifystatus` {% hint style="warning" %} guid is received as a receipt from the `verifysourcecode` method. {% endhint %} **Example** ``` https://fonscan.io/api ?module=contract &action=checkverifystatus &guid={identifierString} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ------------------------------------------------- | | **guid** | `string`used for identifying verification attempt | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": "Pending in queue", "status": "1" } ``` {% hint style="info" %} Return Options: `Pending in queue` | `Pass - Verified` | `Fail - Unable to verify` | `Unknown UID` {% endhint %} {% endtab %} {% endtabs %} # Logs ?module=logs {% hint style="success" %} ### `https://fonscan.io/api?module=logs` {% endhint %} ## Get Event Logs by Address and/or Topic(s) `getLogs` Event logs for an address and topic. Use **and/or** with the topic operator to specify topic retrieval options when adding multiple topics. Up to a maximum of 1,000 event logs. **Example:** ``` https://fonscan.io/api ?module=logs &action=getLogs &fromBlock=1379224 &toBlock=13792288 &address=0x33990122638b9132ca29c723bdf037f1a891a70c &topic0=0xf63780e752c6a54a94fc52715dbc5518a3b4c3c2833d301a204226548a2a8545 &topic1=0x72657075746174696f6e00000000000000000000000000000000000000000000 &topic0_1_opr=or ``` {% tabs %} {% tab title="Request params" %} ***\*=required field***
ParameterDescription
fromBlock*integer block number to start searching for logs. latest is also supported
toBlock*integer block number to stop searching for logs. latest is also supported.

Note can be same as fromBlock if looking at logs for a single block
address*string 160-bit code used for identifying contracts. An address and/or topic is required.
topic0*string for first required topic.
topic1string for 2nd optional topic.
topic2string for 3rd optional topic.
topic3string for 4th optional topic.
topic0_1_oproperator when topic 0 and 1 are used. Either and or or
topic0_2_oproperator for topic 0 and topic 2. Either and or or
topic0_3_oproperator for topic 0 and topic 3. Either and or or
topic1_2_oproperator for topic 1 and topic 2. Either and or or
topic1_3_oprthe topic operator for topic 1 and topic 3. Either and or or
topic2_3_oprthe topic operator for topic 2 and topic 3. Either and or or
{% endtab %} {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "address": "0x33990122638b9132ca29c723bdf037f1a891a70c", "blockNumber": "0x5c958", "data": "0x", "gasPrice": "0xba43b7400", "gasUsed": "0x10682", "logIndex": "0x", "timeStamp": "0x561d688c", "topics": [ "0xf63780e752c6a54a94fc52715dbc5518a3b4c3c2833d301a204226548a2a8545", "0x72657075746174696f6e00000000000000000000000000000000000000000000", "0x000000000000000000000000d9b2f59f3b5c7b3c67047d2f03c3e8052470be92" ], "transactionHash": "0x0b03498648ae2da924f961dda00dc6bb0a8df15519262b7e012b7d67f4bb7e83", "transactionIndex": "0x" } ], "status": "1" } ``` {% endtab %} {% endtabs %} # Stats ?module=stats # Token ?module=token {% hint style="success" %} ### `https://`fonscan.io`/api?module=token` {% endhint %} ## Get ERC-20 or ERC-721 token by contract address `getToken` Info on name, symbol, supply and type for a token contract address. **Example** ``` https://fonscan.io/api ?module=token &action=getToken &contractaddress={contractaddressHash} ``` {% tabs %} {% tab title="Request params" %}
ParameterDescription
contractaddressstring containing the contract address hash - a 160-bit code used for identifying contracts.
{% endtab %} {% tab title="Example Result" %} ``` { "message": "OK", "result": { "cataloged": true, "contractAddress": "0x0000000000000000000000000000000000000000", "decimals": "18", "name": "Example Token", "symbol": "ET", "totalSupply": "1000000000", "type": "ERC-20" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Get token holders by contract address `getTokenHolders` Returns an array of token holder's accounts and amounts held for a specified token contract address. **Example** ``` https://fonscan.io/api ?module=token &action=getTokenHolders &contractaddress={contractaddressHash} &page={integer} &offset={integer} ``` {% tabs %} {% tab title="Request params" %}
ParameterDescription
contractaddressstring containing the contract address hash of the ERC-20/ERC-721 token
pageoptional nonnegative integer representing the page number used for pagination. 'offset' must also be provided.
offsetoptional nonnegative integer representing the max number of records to return when paginating. 'page' must also be provided.
{% endtab %} {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "address": "0x3887e82dbdbe8ec6db44e6298a2d48af572a3b78", "value": "153737849289497644937838" }, { "address": "0xc894c5de34cb2a3615c737d1276876e44e9700a3", "value": "77247336418828547887499" } ], "status": "1" } ``` {% endtab %} {% endtabs %} ## Get bridged tokens list `bridgedTokenList` Returns an array of bridged token information (uses native bridge application and only returns when applicable - depends on implementation). **Example** ``` https://fonscan.io/api ?module=token &action=bridgedTokenList &chainid={chainid} &page={integer} &offset={integer} ``` {% tabs %} {% tab title="Request params" %}
ParameterDescription
chainIDnonnegative integer that represents the chain id where the original token exists.
pageoptional nonnegative integer representing the page number used for pagination. 'offset' must also be provided.
offsetoptional nonnegative integer representing the max number of records to return when paginating. 'page' must also be provided.
{% endtab %} {% tab title="Example Result" %} ``` { "message": "OK", "result": [ { "foreignChainId": "1", "foreignTokenContractAddressHash": "0x0ae055097c6d159879521c384f1d2123d1f195e6", "homeContractAddressHash": "0xb7d311e2eb55f2f68a9440da38e7989210b9a05e", "homeDecimals": "18", "homeHolderCount": 393, "homeName": "STAKE on xDai", "homeSymbol": "STAKE", "homeTotalSupply": "1484374.775044204093387391", "homeUsdValue": "18807028.39981006586321824397" }, { "foreignChainId": "1", "foreignTokenContractAddressHash": "0xf5581dfefd8fb0e4aec526be659cfab1f8c781da", "homeContractAddressHash": "0xd057604a14982fe8d88c5fc25aac3267ea142a08", "homeDecimals": "18", "homeHolderCount": 73, "homeName": "HOPR Token on xDai", "homeSymbol": "HOPR", "homeTotalSupply": "26600449.86076749062791602", "homeUsdValue": "6638727.472651464170990256943" } ], "status": "1" ``` {% endtab %} {% endtabs %} # Transaction ?module=transaction {% hint style="success" %} ### `https://`fonscan.io`/api?module=transaction` {% endhint %} ## Get transaction info `gettxinfo` Information related to a specified transaction. Includes: * blockNumber * confirmations * from * gasLimit (in wei) * gasPrice (in wei) * gasUsed * hash * input * logs (array) * revert reason * success * timeStamp * to * value (in wei) **Example** ``` https://fonscan.io/api ?module=transaction &action=gettxinfo &txhash={transactionHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | -------------------------------------------------------------------------------------------------------------------------------- | | txhash | `string` containing the transaction hash | | index | optional nonnegative `integer` that represents the log index used for pagination. | | {% endtab %} | | {% tab title="Example Result" %} ``` { "result": { "revertReason": "No credit of that type", "blockNumber": "3", "confirmations": "0", "from": "0x000000000000000000000000000000000000000c", "gasLimit": "91966", "gasPrice": "100000", "gasUsed": "95123", "hash": "0x0000000000000000000000000000000000000000000000000000000000000004", "input": "0x04", "logs": [ { "address": "0x000000000000000000000000000000000000000e", "data": "0x00", "topics": [ "First Topic", "Second Topic", "Third Topic", "Fourth Topic" ] } ], "success": true, "timeStamp": "1541018182", "to": "0x000000000000000000000000000000000000000d", "value": "67612" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Get transaction receipt status `gettxreceiptstatus` Also available through a GraphQL 'transaction' query. `Status` field return: * `0` = failed transaction * `1` = successful transaction **Example** ``` https://fonscan.io/api ?module=transaction &action=gettxreceiptstatus &txhash={transactionHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ---------------------------------------- | | txhash | `string` containing the transaction hash | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "status": "1" }, "status": "1" } ``` {% endtab %} {% endtabs %} ## Get error status and message `getstatus` Also available through a GraphQL 'transaction' query. Includes the following: * errDescription: string with error message * isError * 0 = pass, no error * 1 = error **Example** ``` https://fonscan.io/api ?module=transaction &action=getstatus &txhash={transactionHash} ``` {% tabs %} {% tab title="Request params" %} | Parameter | Description | | ------------ | ---------------------------------------- | | txhash | `string` containing the transaction hash | | {% endtab %} | | {% tab title="Example Result" %} ``` { "message": "OK", "result": { "errDescription": "Out of gas", "isError": "1" }, "status": "1" } ``` {% endtab %} {% endtabs %} # ETH RPC API In addition to the custom[ RPC endpoints documented here](/scanapi/rpc-api-endpoints), the Blockscout ETH RPC API supports 3 methods in the exact format specified for Ethereum nodes, see the [Ethereum JSON-RPC Specification](https://ethereum.github.io/execution-apis/api-documentation/) for more details.These methods are provided for your convenience. In general, custom RPC methods are recommended.The following 3 methods are supported: * eth\_blockNumber * eth\_getBalance * eth\_getLogs In the following examples with the base instance url . When sending a request add /api/eth-rpc to the end of the base url. ## eth\_blockNumber Returns the latest block number in the chain in hexidecimal format. No params are needed.\ Type: POST **Example** {% code overflow="wrap" %} ```json // Request curl -H "content-type: application/json" -X POST --data '{"id":0,"jsonrpc":"2.0","method":"eth_blockNumber","params":[]}' https://fonscan.io/api/eth-rpc // Response { "jsonrpc": "2.0", "result": "0xfa0b0e", "id": 0 } ``` {% endcode %} ## ## eth\_getBalance Returns the balance of a given address in wei. Note the `earliest` parameter does not work as expected because genesis block balances are not currently imported. Parameters are required. **Required Parameters**
TypePOST
Data (string)20 Byte address to check balance
Quantity or Tag (string)Integer value of a block number, or a tag "latest" for the most recent block.
**Example** {% code overflow="wrap" %} ```json // Request curl -H "content-type: application/json" -X POST --data '{"id":0,"jsonrpc":"2.0","method":"eth_getBalance","params":["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045","latest"]}' https://fonscan.io/api/eth-rpc // Response { "jsonrpc": "2.0", "result": "0x1d863bf76508104fb", //34039260923474019579 "id": 0 } ``` {% endcode %} ## ## eth\_getLogs Returns an array of logs matching a specified filter object. Params are optional based on data you want to receive. From more information, see this [post on eth\_getLogs](https://medium.com/alchemy-api/deep-dive-into-eth-getlogs-5faf6a66fd81). Note: Never returns more than 1000 log entries. You can use pagination options to request the next page. Pagination options params: {"logIndex": "3D", "blockNumber": "6423AC"} which include parameters from the last log received from the previous request. These three parameters are required for pagination. **Parameters**
TypePOST
address
(string, array)		20Byte contract address or list of addresses to collect logs from.
fromBlock
(Quantity/Tag)		Integer block number, "latest" (default) for the last mined block or "pending", "earliest" for not yet mined transactions.
toBlock
(Quantity/Tag)		 Integer block number, "latest" (default) for the last mined block or "pending", "earliest" for not yet mined transactions.
topics
(string, array)		Array of 32 Byte DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options
paging_optionslogIndex and blockNumber explained above.
**​** **Example Query** {% code overflow="wrap" %} ```json //Request curl -H "content-type: application/json" -X POST --data '{"id":0,"jsonrpc":"2.0","method":"eth_getLogs","params":[{"address":"0xc78Be425090Dbd437532594D12267C5934Cc6c6f","paging_options":{"logIndex":"3D","blockNumber":"6423AC"},"fromBlock":"earliest","toBlock":"latest","topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}]}' https://fonscan.io/api/eth-rpc ``` {% endcode %} {% code overflow="wrap" %} ```json //Response (end) {"address":"0xc78be425090dbd437532594d12267c5934cc6c6f","blockHash":"0x574755e06bf0cec6d59a8cc7db183d4545a90242d03d5bc3806681277356cf4b","blockNumber":"79D4CF","data":"0x000000000000000000000000000000000000000000000c81c6f8fe7064224e6e","logIndex":"66","removed":false,"topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef","0x0000000000000000000000000000000000000000000000000000000000000000","0x00000000000000000000000078c04412a6eb2f524ccf50b5f3d863a82e2f8d6f"],"transactionHash":"0xd35fe29c81484258f38b4848a4d44f54f3dc0b9b3d10ad094b8cd5f3a4815e64","transactionIndex":109,"transactionLogIndex":102,"type":"mined"},{"address":"0xc78be425090dbd437532594d12267c5934cc6c6f","blockHash":"0xcb58a082f58bea43dfb6be8addf97c915190175b9f0f0abc1e05bfd02573f010","blockNumber":"7BA949","data":"0x000000000000000000000000000000000000000000000c81c6272987dea5867a","logIndex":"56","removed":false,"topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef","0x0000000000000000000000000000000000000000000000000000000000000000","0x0000000000000000000000001082e1c4a9c9f946ba102667a14f206c0f81e147"],"transactionHash":"0xd12770e7a1dfa759f6a645981e4bd1d75d2ed131b52565e436bce90b5b39f137","transactionIndex":137,"transactionLogIndex":86,"type":"mined"}],"id":0} ``` {% endcode %} # White Paper
# Background overview With the continuous evolution of blockchain technology, public chains have become one of the most competitive fields worldwide. As the infrastructure of blockchain technology, public chains are decentralized, highly secure, reliable, and flexible. And advantages such as scalability, communityization and ecological construction, as well as innovation and customization are changing the traditional economic and social development model. Today, the public chain field is showing two significant trends: on the one hand, more and more blockchain technologies are used in the financial field, such as decentralized finance (DeFi), digital asset transactions, etc.; on the other hand, the public chain Progressively achieve higher performance and scalability to cope with growing transaction needs. However, existing public chains still have a series of problems when facing these challenges. Among the many existing public chains, performance issues are the most prominent. For public chains represented by Bitcoin and Ethereum, under high transaction loads, problems such as extended transaction confirmation time and rising transaction fees have become constraints. In this context, the FSC Ecological Development Fund created the FON smart chain, which is based on the "consensus trust" mechanism and encryption algorithm of the blockchain. Every transaction in the user scenario is recorded on the blockchain and does not rely on the third party. The three-party intermediary agency is completely open, transparent and traceable, establishing an ecosystem that is trusted by all people, and achieving efficient consensus, multiple application scenarios, scalability, high performance, high security, high-speed access, and efficient operations. FON Smart Chain is a decentralized, efficient and energy-saving ecological public chain. Programmable smart contracts are seamlessly compatible with the Ethereum network, reducing development and migration costs. In addition, decentralized DApps created on the FON smart chain can include privacy expansion, liquidity mining, DeFi financial management, privacy Swap, lending, cross-chain transactions, NFT, social networking, payment, entertainment, e-commerce and other application directions. The FON smart chain will establish point-to-point direct and reliable trust, remove the interference of intermediaries in business scenarios, form a new digital currency system, payment method, and credit mechanism, and create a high-efficiency, low-cost, and safer value ecosystem chain. # Introduction to FON smart chain FON Smart Chain (referred to as FSC or FONChain smart chain), FON smart chain is a brand new public chain. The FON Smart Chain relies on a system of 21 active validators with proof-of-stake (APoS) consensus that supports short block times and low fees. The validator candidate with the most stakes will become the validator and produce blocks. Double signature detection and other slashing logic ensure security, stability and chain finality. In addition to the 21 active validators, FSC will also introduce more validators, such as another 20 inactive validators, as backups into the validator set, which will be called "candidates." Candidates will create obstacles and charge gas fees in the FSC Mainnet, but have much less chance of being elected than the 21 sets of formal validators. Unavailable candidates will also be cut, albeit to a smaller extent. It is expected that good incentives will be maintained so that candidate validators are willing to ensure quality and help secure the FSC. In the extreme case, if the majority of the 21 active validators are attacked and go offline, in the genesis block, the team set A node to ensure the normal operation of the public chain. The FON smart chain also supports EVM-compatible smart contracts and protocols. Cross-chain transfers and other communications are possible thanks to native support for interoperability. Self-sovereign blockchain: providing security and fairness through elected validators. EVM-comp supports all existing Ethereum tools as well as faster finality and cheaper transactions. Interoperable: comes with efficient native dual-chain communication; optimized for high-performance Dapps that require a fast and smooth user experience. Distributed on-chain governance: Proof of Stake (APoS) brings decentralization and community participation. As a native token, FON will serve as gas for smart contract execution and as a token for staking. motivation The creation and development process of FON Smart Chain has experienced many challenges. FSC is a blockchain ecosystem led by a global distributed autonomous community. Many users in the community are based on consensus DeFi decentralization, from the TRON network to the FSC network. After years of accumulation of DeFi consensus, we jointly created an independent, high-speed, high-throughput, service-oriented public chain through DAO governance voting. FSC has been online since October 22, 2022, and has experienced a year of stable network block production. It is known as: the most active blockchain in the global community (currently there are nearly 1.8 million FON currency holding addresses), and the world's almost completely decentralized blockchain. Blockchain (all FON native coins are 100% circulated, no additional issuance, no reservation), is also the most transparent public chain in the world with the fastest growth rate. Cross-chain and multi-chain ecosystem​ An important lesson to learn from historical data is that “one chain” cannot cover all angles. At its peak, FSC’s daily active users (DAU) exceeded 2 million, and a single GameFi reached 1 million DAU. This creates significant challenges for the network itself and its supporting infrastructure such as RPC/API nodes. For Dapps with massive user bases, multi-chain and cross-chain should be the solution. The FSC core team firmly believes in the future of partitioned chains and multi-chains as it can sustain the growing demand for decentralized computing power and storage. This is consistent with the multi-chain strategy found in many other blockchains in the industry such as ETH2.0 as well as Polkadot, Cosmos and Avalanche. Cross-sharding and cross-chain/multi-chain interoperability will be key topics in recent years, and FSC token developers and corresponding communities are committed to realizing the vision of FSC operating at the crossroads of the future of decentralized blockchains. # Design Principles Build an independently operating blockchain system in the FON smart chain ecosystem, and the FON smart chain will not rely on any other network. The design of FSC follows the following principles: Independent blockchain: Technically speaking, FSC is an independent blockchain rather than a Layer 2 solution. Most of FSC's basic technology and business functions should be self-contained, so that it can run normally even if other supporting facilities are temporarily stopped. Ethereum compatible: The first practical, widely used smart contract platform was Ethereum. In order to connect with relatively mature applications and communities, FSC chose to be compatible with the existing Ethereum mainnet. This means that most Dapps, ecosystem components and tools will be compatible with FSC without modification or only minor changes; FSC nodes only require similar or slightly higher hardware specifications and operational skills to operate. This implementation should provide room for continued compatibility between FSC and future versions of Ethereum. Based on equity pledge consensus and on-chain management: The consensus based on equity pledge (APoS) is more environmentally friendly and provides more flexible options for community governance. It can be expected that this consensus will have better performance than the PoW consensus, that is, the block generation time is short and the transaction processing capacity is high. Tokenomics The total amount of FON native coins in the FON smart chain is 26 million, and no additional issuance is allowed. After the FON smart chain is launched, the genesis contract has been open sourced at the Github address: 1. The initial team destroys 2 million coins 2. The creation team holds 800,000 coins 3. Through DEX, ecological mechanisms and team profits, \~969,679 FON were successively destroyed. Destruction address: 0x00000000000000000000000000000000000dEaD The current FON quantity is 100% in circulation. There is no pre-sale or ICO for the FON native currency. All FON tokens except for the team have been mined and put into circulation. # Application target The goal of FON Smart Chain is to use self-developed public chain technology and combine it with the characteristics of blockchain technology to build a fair, open and comprehensive application system. Solve the trust and fairness issues currently faced by the industry and make the entire competitive environment more fair, open and efficient. FSC's mission is to build a complete value ecosystem for global businesses and users in the blockchain era, and hopes that this ecosystem can provide protection for users' free will and personal value, especially the value of time. The major platforms are establishing barriers in the business world, splitting the entire crypto world, and turning into isolated islands one after another. The bridges between various economies have long been ruthlessly torn down. Not only that, they have also built high-rise buildings. of walls. FSC hopes to provide a more ideal ecological environment for global users in the blockchain era and achieve interoperability between independent ecologies. FSC will build bridges between each continent, allowing everyone to understand this blockchain technology from a new dimension. A new world of encryption is being built. The original design intention of FSC is to build a multi-dimensional public chain system. Through cross-chain technology, a complete cross-chain solution is built to be mounted on the FSC public chain, and the unified digital currency produced by blockchain technology is used for rewards: ■ Token economic solutions ■ Multi-application interoperability (digital currency transactions, DeFi, NFT) solutions ■ Digital asset issuance and circulation ecosystem ■ Payment ecological interoperability solution When FSC participants make contributions to FSC, we will provide them with corresponding reasonable returns based on the calculation of the contribution mechanism. As a commercial application-level blockchain solution, the ecological construction and transformation and upgrading problems of third-party commercial institutions can also be solved through the application of FSC. FSC will completely reshape the existing Internet operating model, transform the economic incentive system itself into a system that can circulate within the system, and create a completely decentralized Internet value transmission ecosystem that is also a completely open community ecosystem that transcends National boundaries allow every participant to obtain corresponding value expression. # Advantages of implementation Thanks to the advantages of continuously developed and innovative blockchain technology, extensive commercial applications, and refined governance, FSC is competitive in the following aspects: technology FSC has very mature and powerful technical support. It has accumulated rich industry and technical experience in the fields of blockchain bottom layer, encrypted communication, mathematics, Web3, information technology, etc., and has achieved industry-leading achievements in the development and application of blockchain technology. Leading breakthrough. Industry resources The FSC team brings together senior people from multiple industries with many years of practical operating experience and deep insights into industry development. In addition, the FSC team will sign strategic cooperation agreements with top leading companies in the target industry, which will provide strong support for FSC to enter applications, in order to truly promote FSC to access more projects and developers. business governance Different from general public chains, FON smart chain has a clear and clear strategic plan for the target industry, and is more focused and professional with the characteristics of distributed decentralization, non-tampering, encryption security and point-to-point value transmission of blockchain technology. , to penetrate target industries and quickly gain market share. Money management FSC's fund management will strictly abide by the principles of fairness, justice and openness, with the development of the FSC platform as its primary purpose. The FSC team specializes in safekeeping and ensuring the safety and sustainability of funds. The use of all funds in the FSC public chain and the FSC Ecological Development Foundation will be disclosed to all investors on a regular basis to ensure the openness of the use of funds. Expansion capacity The target industries of FSC are trillion-level blockchain infrastructure and encryption markets. The development team has formulated a complete governance structure to effectively manage matters such as general proceedings, code management, financial management, salary management and privileged operation scope. to ensure sustainable development. FSC perfectly inherits the characteristics and advantages of traditional blockchain ecosystem technology, and solves the current technical bottleneck of blockchain, truly integrating blockchain with commercial applications. In addition, FSC has vigorously and continuously invested in the research and development and innovation of business technology represented by blockchain technology, applying it to enhance the value of traditional industries and promote the vigorous development of blockchain technology in various industries, supplemented by A clear strategic development direction to create a mutually beneficial and win-win blockchain public chain ecosystem in the future. # Ecological sector overview The FON Smart Chain ecosystem is a comprehensive decentralized platform designed to empower individuals and organizations by leveraging innovative blockchain technology. With a strong focus on speed, scalability and security, the ecosystem aims to revolutionize enterprises The approach to operations and individual transactions provides a solid foundation for a wide range of applications, including DeFi, supply chain management, gaming, and more. The core of the FON Smart Chain ecosystem is: FON and Roselle. FON is the native currency of FON Smart Chain Tokens issued to encourage users and third-party partners to participate in ecological construction and other activities are redeemable for value resources and rights within the FON smart chain. At the same time, FON smart chain, as an underlying infrastructure that integrates multi-form digital assets, can derive more other smart assets through financial smart contracts. Roselle is FSC’s first benchmark ecology, a ten thousand times ecology Its economic model has decentralization, scarcity, liquidity, applicability, provides users with pledge rewards, participates in ecosystem growth and other benefits. Roselle is designed to be a secure and efficient medium of exchange that supports all trading ecosystems. FON Smart Chain currently has officially launched products and ecological sectors: RosSwap: RosSwap is the first new DEX-RosSwap based on the FON Smart Chain (FSC) public chain. Time Farm Gamefi: Time Farm is a decentralized blockchain game based on FON intelligent chain operation. HieSwap: HieSwap, a cross-chain protocol invested by RosSwap Labs, has officially been launched on multiple public chains. Currently, the protocol has achieved cross-chain conversion between seven chains: FONChain, BNBCChain, HECO, Ethereum, OKXChain, Polygon and TRON. Myth NFT: Myth NFT cards are divided into four rarity types, namely: creation, classic, rare, and myth. Each unique NFT designed by civilizations from ancient times to the present is a source of equity dividends. # RosSwap RosSwap is the first new DEX based on the FON Smart Chain (FSC) public chain. RosSwap is committed to maximizing the use of virtual currency assets for you! RosSwap provides higher security, more convenient and faster transactions, and more open and transparent on-chain activities. The tokens after transactions can also be managed on TokenPocket, MetaMask or other mainstream EVM wallets. Open and transparent RosSwap is constructed on open source software. The website and all smart contracts are public to maximize transparency. The source code of RosSwap's smart contracts has been verified on FonScan. Advantages of RosSwap The team brings together top talents in the fields of blockchain, finance and technology, and has rich industry experience. We are committed to providing users with innovative decentralized trading experiences and ensuring the security and reliability of the transaction process. The platform not only focuses on technological innovation, but also actively explores and adopts industry best practices to provide users with a more stable and secure trading environment. Low fees RosSwap runs on the FON Smart Chain. Compared with Ethereum or Bitcoin and Binance Smart Chain, the FON Smart Chain has low transaction costs. RosSwap’s transaction fees are also much lower than other top decentralized exchanges. So, this is definitely killing two birds with one stone for you. Decentralization Start trading directly from your wallet app. Unlike centralized exchanges like Binance or Coinbase, RosSwap does not hold your funds while trading: you have 100% ownership of your cryptocurrency. RosSwap product equity As the trading volume increases, DEX generates a certain amount of fee income. We do not attribute all of this income to the team. We package part of the income generated by DEX into equity and distribute it to users who participate in equity. According to your own needs, you can choose whether to participate in this equity product. Rosswap product equity will be determined based on the actual profit of all Rosswap products. During the product equity subscription period, you have a certain amount of thinking (hesitation period) and can participate flexibly. and retrieve Product equity is divided into three types of equity rewards according to official announcements 1.DEX profits use USDT as the settlement unit, and pledged FON as the participating equity 2. Provide liquidity to RosSwap and pledge to obtain diversified token rewards 3. Stake Myth NFT to obtain benefits from various combination extensions SWAP functionality and user experience Provide innovative decentralized trading functions, including LP liquidity, farm pool, etc. Users can easily deposit assets into the liquidity pool and earn equity token income. The platform interface is simple and intuitive, suitable for all types of blockchain traders. Whether they are beginners or professional trading experts, they can all enjoy a convenient trading experience. RosSwap will use the FSC ecosystem to create an open digital platform that integrates transactions, governance, wallets and creativity, gathering the power of the global community to promote the continuous advancement and growth of the FSC ecosystem. RosSwap not only greatly enriches the blockchain ecology, but will also leave a milestone in the history of DEFI development. RosSwap will always uphold the core values of cooperation, innovation, diversity and sustainability, continue to explore innovative possibilities, and lead the new future of digital finance. # Time Farm Time Farm is a decentralized blockchain game based on the FON smart chain. It is currently a popular GameFI chain game. Time Farm not only combines NFT and blockchain mining, but also incorporates the currently popular Farm elements, making the entire game richer in content. Time Farm technical features Time Farm is an on-chain game based on the underlying public chain technology of Web3. The data is uploaded to the chain throughout the entire process, and the node blocks are packaged, making it open and transparent. Time Farm has carried out innovation and reform on the basis of the chain game Farmer World. Be fair, just and open. Highlights of Time Farm: 1. The four resource import and export tokens are all Roselle, which solves the pain point of the continuous increase in game tokens. The resources in the game, meat, wood, and stone, are benchmarked against gold, and gold is benchmarked against Roselle. 2. All resources are zero pre-mined, everything starts from scratch, and all participants are on the same starting line to ensure fairness and justice. 3. Draw blind box double-sign random numbers to eliminate the possibility of anyone grabbing advanced equipment and ensure fairness and openness. 4. The 4,200 blind boxes will never be issued again, and participants must synthesize their own equipment to ensure the sustainable operation of the game. 5. The game integrates fun, relevance, and circulation, and is complementary and interlocking. Be competitive in the GAMEFI industry! 6. Game token permissions are discarded and plunged into a black hole. The quantities of meat, wood, stone, and gold tokens are 40W, 37W, 30W, and 118W respectively. They will never be issued additionally to ensure the automatic balance principle of the game token resource market. 7. Just click once every 8 hours, 12 hours, 24 hours or 48 hours a day. You don’t have to stare at your phone all the time to play, which saves time, effort and money. 8. The NFT trading market is online in the FSC area of AVE, and equipment can be traded at any time, making it more attractive. TIMEFARM is the first NFT section of AVE. AVE has been in the currency circle for many years and has many users in the currency circle. When the value of the game becomes larger and larger, a lot of traffic will come in. 9. When game resources are turned into tokens, there are 5-12% transaction fees, which are packaged into financial products, 30% of which are distributed to Roselle equity pledgers. Time Farm Leverage Logic 1. Chain games empower Luoshen and are also a tool for evangelism in the entire community: The initial equipment is purchased fairly through a million-level blind box, and everyone who grabs it will make money. At the beginning, no one understood the logic of the game. Many people did not rush to grab it, but later quickly bought Luo, exchanged resources, and combined equipment, and they also made money. This is playing to earn evangelism. 2. Three lever logic The first lever: no matter what equipment you combine, no matter how much your principal is, your output income will be there every day, and the income will continue to be stable. The second lever: when you produce resources, you can switch to Roselle, and Roselle is the first benchmark of FSC and a ten thousand-fold ecosystem. Through various empowerment and evangelism, Roselle will rise, and you will make money again, and you can do so at any time. Realize. The third lever: One day, when you have earned enough, you stop playing. You can go to the NFT trading market at any time to trade at the price you want, and finally your equipment will be sold back to its original value or even higher. 3. Through the game, you not only earn free resources, but also get dividends from the rise of Luoshen. You can also sell your equipment NFT at a high price. Invest once and earn three times. This is the logic of leverage. Through leverage logic, you will find that making money is so easy. Chain game Time Farm creates miracles! The emergence of Time Farm breaks the bottleneck of existing blockchain games and the business logic of traditional game development, returns game revenue and value to players, and subverts the traditional game model with a new gameplay that combines blockchain technology and concepts, to better protect the interests of players, allowing players to not only enjoy the fun of the game, but also obtain benefits from it, and ultimately achieve a win-win situation between the platform and players. # HieSwap Money never sleeps, but always flows to more efficient places. When the HieSwap founding team entered the DeFi field in early 2022, they were surprised to find that cross-chain transactions were so cumbersome and inefficient. So the team created HieSwap - reducing the cross-chain transaction time of the blockchain to 3 seconds. This is the first time in the industry that the cross-chain transaction time has been shortened to seconds! This is a landmark breakthrough and another major infrastructure change in the DeFi industry after the Uniswap AMM mechanism, which will change the efficiency of cross-chain transactions and the future pattern. HieSwap's original cross-chain technology is not only fast, but also has ultra-low handling fees, allowing your assets to circulate freely in various chains safely. Another particularly gratifying feature of HieSwap is the cross-chain exchange of public chain coins, which solves the gas fee problem in one go and eliminates the need to manually transfer handling fees to the corresponding chain. HieSwap, the cross-chain protocol HieSwap invested by RosSwap Labs is officially connected to multiple public chains and launched online. Through the HieSwap cross-chain protocol, users can complete asset transfers between different chains in an environment with low transaction fees and low slippage. It is reported that the transaction time on HieSwap can be completed in 3 seconds at the fastest, which is 15 times faster than the transaction time of other similar cross-chain solutions on the market. In addition, HieSwap's stablecoin exchange between multiple chains has sufficient liquidity for each chain, effectively reducing the slippage risk of cross-chain users. In the future, it will access more aggregate transactions between chains and will support cross-chain transactions. Exchange tokens and give users multiple choices. Cross-chain principles and mechanisms HieSwap is a decentralized trading platform deployed on multiple public chains (currently supporting seven chains: FSC, BSC, Heco, Oec, TRON, Polygon and ETH). It has the characteristics of security, low transaction fees, and fast speed. It integrates cross-chain and aggregation transactions, and is committed to allowing all users to enjoy ultra-low fees and low slippage to complete the exchange of assets between single or dual chains. HieSwap advantages 1. Security This is the most basic guarantee. HieSwap has taken security into consideration from the beginning, and uses unique technology to ensure that users will not encounter security problems during use. 2. Ultra-low fees Saving you money is our hope. In HieSwap, you only need to pay low cross-chain handling fees to complete cross-chain transactions quickly and safely. Gas fees and target chain transaction fees will be charged by the corresponding chain. 3. As fast as lightning Fast is our original intention and goal in creating this platform. In the ever-changing blockchain, time means efficiency and money. Through our original cross-chain technology, we have improved cross-chain transactions from more than 3 minutes to less than 9 seconds. Cross-chain transactions have since entered the era of seconds. DeFi innovation has brought new vitality to the blockchain, promoted the birth of decentralized exchanges (DEX), and been recognized by users. However, the inconvenience and long time of cross-chain transactions bring a very bad experience to users. In the ever-changing blockchain market, time is money, because extremely long transaction times bring huge economic losses to users. HieSwap uses original technology to reduce blockchain cross-chain transactions from the previous minutes to seconds, up to 3 seconds at the fastest. It only charges low transaction fees for cross-chain transactions while ensuring security, which gives users Brings great convenience. It is our mission to allow users to freely move their assets, so that your money never sleeps. # Myth NFT Myth NFT cards are divided into four rarity types: Creation, Classic, Rare, and Myth. The four main rarity categories are designed by civilizations from ancient times to the present. Each card is a unique NFT. The total number of Myth NFTs is designed to be 20,000. Design element structure: Designed with four major rarities A total of 10222 pictures of the four characteristic themes of creation Creation: Chiyou 2555, Fuxi 2555, Pangu 2555, Xuannv 2555 The classics are divided into three features and five features, a total of 8600 pictures Three classic features: 1,500 interstellar pictures, 1,500 magic pictures, and 1,300 dark pictures. Five classic features: 800 pictures for King, 800 pictures for Xiao Wang, 900 pictures for J, 900 pictures for Q, and 900 pictures for K The rarity is divided into two characteristics and six characteristics, a total of 998 pictures Rare two features: Bible (Gabriel 83, Satan 83, God 83) and Olympus (Poseidon 83, Hades 83, Zeus 84) Six rare characteristics: 85 pictures in spring, 85 pictures in summer, 85 pictures in autumn, 85 pictures in winter, 80 pictures in the sun, and 79 pictures in the month. The myth is divided into one character and seven characters 182 pictures One feature: 91 photos of the Queen Mother of the West Seven characteristics: 13 pictures of Nuwa, 13 pictures of Luo Shen, 13 pictures of Chang'e, 13 pictures of Xihe, 13 pictures of Weaver Girl, 13 pictures of Jingwei, and 13 pictures of Leizu. NTF Casting obtains equity interest dividend source Equity Equity Award 1 FONCHAIN network-wide block rewards generate every gas fee These will be awarded as equity to the Myth NFT contract as dividend rewards 10% of the gas generated by the entire network will be rewarded to Shinhwa NFT staking users Equity Equity Award 2 Every transaction fee generated by Rosswap on DEX across the entire network These will be awarded as equity to the Myth NFT contract as dividend rewards 10% of the handling fees generated by the entire network will be rewarded to Shinhwa NFT staking users Equity Equity Award Three The NFT transaction fee generated by the entire network of the NFT trading market These will be awarded as equity to the Myth NFT contract as dividend rewards 10% of the handling fees generated by the entire network will be rewarded to Shinhwa NFT staking users Equity pledge cycle Participating in the liquidity of Shinhwa NFT equity interests will have a 90-day extension of the pledge period. After pledging, you will be able to withdraw your liquidity after 90 days. Therefore, you will no longer receive equity equity dividends. In the equity interests you have participated in, you You can continue to participate, and the current liquidity of participation will be postponed for 90 days based on the last participation in the block. Equity dividends are substantial Equity interests will be distributed in the equity equity dividend contract on the 20th of each month. Make a 100% distribution. If you participate before the equity dividend is distributed, you will receive the equity dividend. Equity equity dividend ratio Genesis: 49% Classic: 43% Rare: 6% Mythic: 2% Precautions · Forge will have four types of rarities, Genesis, Classic, Rare, Mythic · Casting costs will fluctuate to a certain extent. Please check the casting page for details. · Reward three major rights and interests: FONCHAIN block reward, Rosswap income, NFT trading platform income · Rewards will be distributed every month, and you will not be able to get rewards if you do not stake. # Token economy The FON native currency has a profound logical connection with the value, incentive, governance and security of the underlying FON smart chain, which embodies the value characteristics of FON. ■ From the perspective of value, FON embodies the carrier of “trust value” and “consensus value”; ■ From an incentive perspective, FON is an economic reward that encourages the participation of “bookkeepers” in the network; ■ From a governance perspective, FON native currency is the equity certificate for participating in the FON smart chain network; ■ From a security perspective, the existence of value incentives improves the network security of the FON smart chain. FON will run on the FON Smart Chain just like ETH runs on Ethereum, therefore, it is the "native currency" of the FON Smart Chain. This means that in addition to FON being used to pay most of the fees on the FON smart chain, it will also be used to: ■ Pay the “fee” to deploy smart contracts on the FON smart chain ■ Pledge the selected FON smart chain verifier and receive corresponding rewards # Economic model The FON smart chain will issue FON public chain coins. FON is a token issued to encourage users and third-party partners to participate in ecological construction and other activities, and is redeemable for the internal value resources and rights of the FON smart chain. At the same time, FON smart chain, as an underlying infrastructure that integrates multi-form digital assets, can derive more other smart assets through financial smart contracts. In the future, the FSC public chain will drive the value growth of FON through more innovative models. FON economic model Fonvity (FON) Smart Chain Explorer The total number of native FON tokens is 26 million. The top 21 nodes will receive node block rewards FON Smart Chain is used for effective governance proposals to enrich the healthy development of the ecosystem Creating a node requires a creator, who pledges 9999 FON to create it. The maximum number of alliance nodes is 99, and cannot be created after exceeding the limit. The top 21 nodes are core nodes and can directly initiate core proposals for governance. The person who created the node can exit the alliance node at any time, and 9999 FON will also be returned. Node election method, voting for nodes through FON pledge Nodes refresh their rankings every three hours FON runs on FSC in the same way that ETH runs on Ethereum, so it is an FSC "native token". This means that in addition to being used to pay most handling fees on the FON smart chain and DEX, FON will also be used for: 1. Pay the handling fee for deploying smart contracts on FSC 2. Pledge the rights and interests of the selected FSC verifiers and obtain corresponding rewards. 3. Perform cross-chain, transaction and other operations, such as FSC transfer token assets Roselle economic model Introduction Roselle is the platform token of RosSwap and the NFT trading market. It is a value token with product support. Roselle is also the first benchmark ecosystem and ten thousand times ecosystem of FSC. Its economic model has decentralization, scarcity, liquidity, applicability, provides users with pledge rewards, participates in ecosystem growth and other benefits. Roselle is designed to be a secure and efficient medium of exchange that supports all trading ecosystems. origin Completed with multiple collateral mining • Wfon-Usdt LP staking mining • NFT staking mining • NFTs pledge mining • Wfon native currency pledge mining total amount 2.1 million pieces Mining cycle: 5184000 Block mining ends Mechanism details Transaction rate • Buy-in rate: 3% • Selling rate: 3% • Transfer fee: 3% Conditions of issuance The generated rates will first be temporarily stored in the Roselle token contract. When the total of 10 Roselles is completed, it will be automatically executed by the contract. • 37% of Roselle liquidity converted to WFON • 62% of Roselle will be burned (View burning deflation address) • 1% of Roselle will be added to the Roselle-Fon flow pool Roselle generates transaction reward distribution method Reward distribution ratio: 60% will be allocated to the market, 40% will be transferred to the black hole to destroy FON 60% of the rewards will be accumulated (value equity system) and distributed in the form of equity dividends ecological development Ecological Development Fund 23% Ecology will better operate and build Roselle What is WFON coin? WFON is an FRC-20 token on the FON smart chain that is linked to the price of FON. WFON is an FRC-20 token on the FON smart chain linked to the FON price (1:1). Although FON, the native token of FON smart chain, can be used to pay for gas, WFON cannot. But WFON has wider uses than FON and has become very popular in the decentralized finance (DeFi) ecosystem. Almost all wallets in the FON smart chain network will support WFON. Wrapped FSC(FON) is a token pegged to FSC(FON). Wrapped FON coins are suitable for many platforms and decentralized applications that support FRC-20 tokens. Although (FON coin) can be used to pay network transaction fees, its function is different from the FRC-20 token (WFON coin). You can easily convert FON coins into wrapped FON coins through the wrapping process. You can also exchange packaged FON coins back for FON coins at any time. Both wrapping and unwrapping follow a 1:1 ratio, meaning there are no additional fees other than transaction fees. By interacting with the packaging FON coin smart contract, you can manually wrap FON coins, and the smart contract will store your FON coins and return an equal amount of wrapped FON coins. The decentralized finance (DeFi) ecosystem of FON Smart Chain is quite large, and the use of wrapped FON coins provides more opportunities for pledge investment. Why do we need to package FON coins? At first, the confusing point was: why does a token like wrapped FON coins exist? Doesn’t the FON blockchain already have FON coins? The first thing to understand is that not every token on FON is technically similar. The network allows developers to create new rules and standards for cryptocurrencies. One example is in the form of FRC-721, which gives us non-fungible tokens (NFTs). These are very different from FON coins or FRC-20 tokens. Developers have a lot of room for customization when creating these digital assets. Therefore, while (FON coins) can be used to pay for gas on the FON smart chain, FON coins cannot be used in all decentralized applications. Today, most DeFi decentralized applications accept FRC-20 tokens for investment and staking. If you want to inject (FON coins) into liquidity pools or use them as collateral, it will be much easier to use (WFON coins) in the FRC-20 version. This provides maximum compatibility across the entire blockchain and saves time in developing new smart contracts. # Staking and governance Equity pledge and on-chain governance APoS realizes decentralized community governance. You can see similar ideas from other networks, notably Cosmos and EOS. Its core logic can be summarized as follows. 1. Token holders, including validators, can “lock” their tokens into staking. Token holders can delegate their tokens to any validator or a validator candidate. They can then reselect a different validator or candidate to delegate their tokens to. 2. All validator candidates will be sorted by the number of delegated tokens they have received, and the top ones will become the real validators. 3. The verifier and the delegator can release the pledge at any time through the verifier’s rights. FSC equity pledge Ideally, such staking and reward issuance logic should be included in the blockchain and executed automatically when new blocks are produced. This is how the Cosmos Hub, which uses the Tendermint consensus library like the FON smart chain, works. FSC wants to be as compatible with Ethereum as possible, and implementing APoS directly on it is a huge challenge and pressure. This is especially true when you consider that Ethereum itself may be migrating to a PoS consensus protocol in short order (or longer). In order to maintain the compatibility of Ethereum, our staking logic in FSC is: 1. The pledged currency is FON because it is the native currency on FSC. 2. In FSC’s equity pledge and delegation behavior, the FSC validator set is determined by its equity pledge and delegation logic. The equity pledge module built on FSC rewards distribution on FSC occurs every 3 hours. FON is the token for FSC equity pledge. To maintain compatibility with the Ethereum consensus protocol, including upcoming upgrades, FSC has chosen independent staking management. In the FSC stake staking module. It will accept FSC stakes from FON holders and calculate the set of nodes with the largest stakes. Every 3 hours, the ranking of block producers is refreshed and FSC is notified to update its validator set. Before generating a new block, existing FSC validators regularly check whether there is a "ValidatorSetUpdate" message forwarded to FSC. If so, they will update the validator set after a certain height (i.e. a predefined block interval). For example, if FSC generates a block every 5 seconds and the check period is 240 blocks, then the current validator set will check and update the validator set for the next period in 1200 seconds (20 minutes). award Validator set updates and reward distribution both occur every 3 hours. This can better make the FSC network validators healthier and also make the validators more active. Rewards will be issued directly to the validator address. # Circulation example In the future, the circulation value of FSC will be reflected in the following aspects: Ecological circulation Based on the FON smart chain, many applications will be derived, such as mining wallets, DEX exchanges, blockchain payments, etc., while FON and its tokens on the chain can be exchanged with all digital currencies, supporting the ecosystem. All circulation transactions and payments in all aspects, such as receipts and payments, transfers, legal currency transactions, deposits, withdrawals, currency voting, STO gateways, currency distribution, lending, charity, games, shopping malls, etc., are all served by FON tokens. And settle with legal currencies from all over the world. In addition to circulation within the FON smart chain ecosystem, it will also be circulated within third-party applications developed based on public chain technology and exist as the only value token. This will accelerate the circulation of FON and its tokens on the chain, add more circulation value attributes to the scarce FON, and increase the overall value and price. In terms of versatility The FON smart chain can adapt to diverse business needs and meet data sharing across business chains. This means that the FON smart chain has a sufficiently common and standard way of recording data, and can represent various structured and unstructured information. , and can meet the cross-chain requirements required as the business scope expands. This provides a value basis for the versatility of FON tokens. This allows FON and its tokens on the chain to circulate more easily in various industries and scenarios around the world. # FSC technology systemFSC will FSC will provide the underlying API of the blockchain for third-party projects to realize the docking of application scenarios and the overlay of digital assets, thereby solving relevant practical problems in the industry. In order to realize this vision, FSC has made corresponding layouts in the underlying design and top-level applications. Fast transaction verification in seconds By optimizing key aspects such as signature algorithms, ledger structures, data operations, serialization, consensus mechanisms, and message diffusion, FSC will achieve fast transaction verification in seconds. Meet the user experience of most financial scenarios in blockchain applications. Storage of massive financial data The double-entry accounting model of the blockchain has been continuously used in the system, accumulating a large amount of data, resulting in a decrease in operating speed. FSC will implement separate storage and sub-table storage mechanisms to achieve mass storage of data. Improved transaction throughput The essence of blockchain is a distributed shared accounting technology, and its distributed characteristics are mainly reflected in distributed consistency rather than distributed concurrent processing. In order to ensure data consistency and prevent the Byzantine Generals problem, some specific links can only be executed serially and cannot be executed in parallel. Through long-term testing and optimization practices, FSC’s processing performance will further significantly improve transaction throughput. Node data fast synchronization FSC will develop a mirroring mechanism that can regularly mirror the local ledger to implement a convenient rollback mechanism. Under a unified consensus, the mirroring label can be specified for rollback. At the same time, it shortens the cycle for new nodes to join the operation. They only need to synchronize the latest image and a small number of recent transaction collections to integrate into the network and participate in consensus verification. Data permission control strategy FSC provides two types of permission control strategies for writing and reading data information. Data information writing permissions, multiple users can be set up under the same account, and corresponding permissions are set for different operations to meet the usage scenarios of multi-party signature control. Data information reading permission, users can grant and revoke data operation permissions to single users or user groups, and user groups can be flexibly configured by users. The data includes user account information, transaction information, etc., and the granularity can be refined to each attribute field of the transaction or account. Diverse expansion development FSC's blockchain structure can meet the needs of different business fields and improve the system's scalability and maintenance efficiency. It can be used to mark assets and asset transfers, and can also provide multi-dimensional event records that cannot be tampered with. It can also be used for traceability to track the circulation process of financial assets. Multiple privacy protections In order to facilitate users to use FSC products and services, in addition to the traditional client generation and saving mechanism, FSC also provides two solutions: network hosting access and private key hardware access (U-key). Network hosting access means mapping usernames and passwords into private keys through a specific algorithm and storing them on the server. The private keys stored on the server side are all encrypted data, and the private keys can only be decrypted on the user side; the hardware private keys are to meet the needs of the financial industry. At the same time, it provides multiple privacy protection functions. First of all, the bottom layer of FSC provides homomorphic encryption. All user data is encrypted and stored and is only visible to the user. Secondly, encryption middleware services are provided, and users can choose according to business needs. Finally, the upper-layer application can encrypt the data during entry, and FSC is responsible for writing and reading the encrypted data generated by the user. Visual operation and maintenance support FSC will provide the visualization tools required for operation and maintenance management. System monitoring services deployed on FSC nodes: support data information monitoring at the business (blocks, transactions, contracts, consensus, etc.), network (networking, delay, throughput, etc.), and system levels (CPU, memory, disk, etc.) . At the same time, it provides a complete log, alarm and notification mechanism to facilitate the maintenance of financial commercial systems. # Proof of Stake Authority Proof Of Staked based on equity (Authority Proof Of Staked) Although Proof of Work (PoW) has proven to be a practical solution for achieving decentralized networks, it is not environmentally friendly and requires a large number of participants to maintain network security. Ethereum and some other networks, such as MATIC Bor, TOMOChain, GoChain, and xDAI, use Proof of Authority (PoA) or its variants in different scenarios, including testnets and mainnets. PoA provides defense against 51% attacks and more effectively prevents some Byzantine nodes from doing evil. Choosing PoA as the underlying consensus is one of the ideal options. At the same time, the PoA protocol has been criticized for being less decentralized than PoW because validators, the nodes who take turns generating blocks, have tremendous power and are prone to corruption and security attacks. Other blockchains, such as EOS, have introduced different types of Delegated Proof of Stake (DPoS), allowing token holders to vote for validator nodes. It makes the network more decentralized and facilitates community management. Inspired by the above, FSC combines DPoS and PoA to reach consensus. The solution adopted is: 1. Blocks are generated by a limited number of validators 2. Validators take turns generating blocks in a PoA manner, similar to Ethereum’s Clique consensus engine 3. The set of validators is selected and eliminated based on on-chain governance of equity pledges Validator node quorum During the genesis block phase of network launch, a number of trusted nodes will operate as the initial set of validators. After the block production begins, anyone can participate as a candidate in the election of validators. The maximum tolerance for validators in the FON smart chain's re-creation block is 99 validators. When there are >99 validators, they will not be able to join as a new validator. certifier. The stake pledge status determines that the top 21 nodes with the most stake pledges become the next set of validators. Such elections and eliminations occur every 3 hours. FON is the token for FSC equity pledge. To maintain compatibility with the Ethereum consensus protocol, including upcoming upgrades, FSC has chosen independent staking management. In the FSC stake staking module. It will accept FSC stakes from FON holders and calculate the set of nodes with the largest stakes. Every 3 hours, the ranking of block producers is refreshed and FSC is notified to update its validator set. Before generating a new block, existing FSC validators regularly check whether there is a "ValidatorSetUpdate" message forwarded to FSC. If so, they will update the validator set after a certain height (i.e. a predefined block interval). For example, if FSC generates a block every 5 seconds and the check period is 240 blocks, then the current validator set will check and update the validator set for the next period in 1200 seconds (20 minutes). safety and finality Considering that more than half of the ½*N+1 validators are honest and trustworthy, PoA-based networks can generally work safely and properly. However, in some cases, Byzantine validators may still manage to attack the network, such as through a "clone attack." In order to ensure FSC security, we encourage FSC users to wait until the received block is confirmed by more than ⅔*N+1 different validators, and can tolerate less than 1/3\*N Byzantine validators. For 21 validators, if the block time is 5 seconds, then ⅔\* N + 1 different validators will take (2/3\*21 + 1)*5 =75 seconds to confirm. Any significant application of FSC will likely have to wait ⅔*N + 1 to ensure a relatively safe end result. Consensus and number of validators Based on the above design principles, FSC’s consensus protocol is to achieve the following goals: 1. The block time should be shorter than Ethereum time, such as 5 seconds or even less. 2. Only need to wait a limited amount of time for the transaction to be finalized, such as about 1 minute or less. 3. There is no inflation. The revenue of the blockchain comes from handling fees, which are paid in the form of FON. 4. Be as compatible with Ethereum as possible. 5. Equipped with an on-chain governance mechanism based on equity pledge. income All FSC validators in the current validator set will receive income from fees paid in FON. Since FON is not an inflationary token, it will not generate mining revenue like the Bitcoin and Ethereum networks. Handling fees are the main revenue for validators. Since FON is also a utility token for other applications, delegators and validators will still receive other benefits of holding FON. Validators’ income is obtained from the fees collected from transactions in each block. Validators receive 85% of the total verification block revenue, and the remaining 15% will enter the official treasury to reward FON ecological users. Each validator will take turns generating blocks with equal probability (if they remain 100% online), so in the long run, all stable validators are likely to receive similarly sized gains. instability The availability of FSC relies on each validator in the validator set in the APoS consensus to be able to generate blocks in time when it is their turn to generate blocks. A validator may miss the opportunity to produce a block for a number of reasons, especially due to hardware, software, configuration or network issues. This unstable operation will harm the performance of the network and bring more uncertainty to the system. FSC has an internal contract that is responsible for recording the blocks missed by each validator. Once this indicator exceeds the predefined threshold, the validator will no longer participate in block production in the current 3 hours, and will no longer receive the allocated rewards, but will be shared by other better validators. In this way, poorly functioning validators will gradually exit. # Cross-chain mechanism FSC uses a proof-of-stake consensus protocol that has a chance of forking and requiring more blocks to be confirmed. A block is signed by only one validator, so it is difficult to rely on one block to verify data from FSC. In order to fully utilize the validator quorum of other chains, an idea similar to many \[Bridge] or Oracle blockchains is adopted: Cross-chain communication requests from FSC will be submitted and executed as transactions on the FON smart chain. The execution of transactions emits `Events`, which can be observed and packaged in some "Oracle\*" to other chains. This type of "Oracle" package does not have Block Headers, Hash and Merkle Proof, but directly contains the cross-chain information of the action, such as the sender, receiver and transfer amount. To ensure the security of the oracle, validators from other chains will form another quorum "Oracle Relayers". Each validator of other chains should run a dedicated process as an Oracle Relayer. These Oracle Relayers will use the same validator key to submit cross-chain communication packages (such as Oracles) to other chains and vote. Any package signed by more than ⅔ \* N+1 Oracle Relayers voting power is as secure as any block signed by ⅔ \* N+1 equal quorum of validator voting power. By using the same validator quorum, it keeps the light client code on other chains and keeps the continuous block updates on other chains. This type of Oracle also has an Oracle ID and type to ensure ordering and correct error handling. Timeouts and error handling There are scenarios where cross-chain communication fails. For example, the relay package failed to execute on FSC due to some coding errors in the contract. Timeout and error handling logic are used in such scenarios. Both networks should repair themselves for identifiable user and system errors or any expected anomalies. For example, when the transfer from other chains to FSC fails, FSC will send a failure event, and Oracle Relayers will perform refunds from other chains; when the transfer from FSC to other chains fails, the other chains will send refund packages to Relayer for relay to unlock. funds. However, unexpected errors or exceptions may still occur during any step of cross-chain communication. In this case, Relayers and Oracle Relayers will find that the corresponding cross-chain channel is stuck in a specific sequence. After the timeout period, repeaters and Oracle repeaters can request "SkipSequence" transactions and the stuck sequence will be marked as "unexecutable". A corresponding alert will be raised and the community must discuss how to handle the situation, such as giving back via the validator's sponsor, or clearing funds during the next network upgrade. Cross-chain user experience Ideally, users would want to use two parachains as if they were one chain. It would require adding more aggregated transaction types to cross-chain communication to achieve this, which would add significant complexity, tight coupling, and maintenance burden. Here other chains and FSC only implement the basic operations of enabling value flow on initial startup, leaving most of the user experience work to the client UI, such as the wallet. For example, a great wallet might allow users to sell tokens directly from FSC onto other chains’ DEX order books in a secure manner. Cross-chain contract events Cross-chain Contract Events (CCCE) are designed to allow smart contracts to trigger cross-chain transactions directly through contract code. This is possible based on: ■ Can provide standard system contracts to serve operations that can be called by general smart contracts; ■ Standard events can be emitted by standard contracts; ■ Oracle Relayers can capture standard events and trigger corresponding cross-chain operations; ■ Dedicated, code-managed addresses (accounts) can be created on other chains and accessed by contracts on FSC, here named "Contract Address on Other Chains" (CAoB). Several standard operations are implemented: ■ FSC to other chain transfer: This is implemented in the same way as normal FSC to other chain transfer and is only triggered through standard contracts. Funds can be transferred to any address on other chains, including the corresponding CAoB of the contract originating the transfer. ■ Transfer on other chains: This is a special cross-chain transfer, while the real transfer is from CAoB to any other address (even another CAoB). ■ Transfers from other chains to FSC: This is achieved through two cross-chain communications. The first time it is triggered by the FSC contract and propagated to other chains, then on the second pass, the other chains will start the normal cross-chain transfer from other chains to FSC, from CAoB to the contract address on FSC. It is important to note that the FSC contract only increments the balance on any transfer in the second pass, and error handling in the second pass is the same as normal other chain-to-FSC transfers. ■ IOC (Immediate-Or-Cancel) Trade Out: The main goal of transferring assets to other chains is to trade. This event will instruct a certain amount of the asset in the CAoB to be traded into another asset if possible, and all results of the transaction, i.e. the source token left and the target token of the transaction, will be transferred back to the FSC. Other chains will handle such relay events by sending an "immediate or cancel" (i.e. IOC order) to the trading pair, and the results will be relayed back to FSC once the next match is completed. ■ Auction Trade Out: This event will instruct other chains to send auction orders to trade a certain amount of assets in CAoB for another asset as much as possible, and transfer all results back to the FSC auction at the end. FSC will launch auction function. Trade Out has some details: ■ Both can have limit prices for transactions (absolute or relative); ■ The final result will be written as a cross-chain package and passed back to FSC; ■ Cross-chain communication fees may be charged for assets transferred back to FSC; ■ The FSC contract maintains a mirror of the balance and outstanding orders on CAoB. No matter what error occurs during Trade Out, the final state is propagated back to the original contract and its internal state is cleared. With the above features, it simply adds cross-chain transfer and exchange functions with high liquidity to all smart contracts on FSC. It will greatly increase the application scenarios on smart contracts and dApps, realizing 1 chain + 1 chain > 2 chains. # Repeater Relayer Relayers are responsible for submitting cross-chain communication packages between two blockchains. Due to the heterogeneous parallel chain structure, two different types of Relayer are created. FSC Repeaters Repeaters used for other link-to-FSC communications are called "FSC repeaters", or simply "repeaters". A Relayer is an independent process that can be run by anyone anywhere, except that the Relayer must register with the FSC and deposit a certain number of refundable tokens. FSC only accepts relay requests from registered relays. The packages they relay will be verified by on-chain light clients on FSC. A successful relay needs to pass sufficient verification and pay gas fees on FSC, so there should be incentive rewards to encourage the community to run Relayer. Oracle Relay The relays used by FSC to communicate with other chains use the “Oracle” model, the so-called “Oracle Relayers\*”. Every validator (and only validators in the validator set) must run the Oracle relay. Each Oracle Relayer observes changes in the blockchain state. Once it captures the cross-chain communication packet, it submits the request for voting. Cross-chain actions will be performed after an Oracle Relayer with 2/3 of the voting power of the other chain's validators votes in favor of the change. Oracle Replayers should wait for enough blocks to confirm finality on FSC before submitting and voting cross-chain communication packages to other chains. Cross-chain fees will be distributed to other chain validators along with normal other chain block rewards. This oracle type of relay relies on all validators to be supported. Since all votes for cross-chain communication packages are recorded on the blockchain, it is not difficult to have a measurement system to evaluate the performance of Oracle Relayers. Worst performers may get their rewards back via another slashing logic introduced in the future. # Hard forks, specifications and dispute resolution Hard forks, specifications and dispute resolution Different distributed ledger systems often differ in their underlying political philosophies and technology choices. The Ethereum project originally promised to be an "unstoppable application" that can realize "code is law". After an important smart contract was hacked, a debate arose about whether what happened could be described as a hack due to the lack of non-code instructions on what the program was intended to do. The differences eventually led to divisions within the community. Because FSC contracts are simple zip files, it can easily contain PDF or other format documents describing the actual intent of the contract. There is no requirement to use this mechanism or for these documents to be legally binding. Nonetheless, in the case of financial applications, if disagreements arise, the legal meaning of the contract that contains them is more important than the software implementation that contains them. It is technically possible to write a non-upgradeable contract. If such a contract governs an asset that exists only on the ledger, such as a cryptocurrency, then this can provide an approximation of "code as law." We leave the discussion of the wisdom contained in this concept to political scientists and reddit. Platform logs in FSC do not have a direct equivalent to a "hard fork" of the blockchain, so abandon the problem transaction chain or fraudulent transaction chain. The only way to do this is to agree outside the band on discarding an entire subgraph of transactions. Since there is no global visibility, this consensus need not include all participants on the network: only those who may have received and processed the relevant transactions. Another consequence of the lack of global visibility is that there is no single point of recording exactly who saw which transaction. Determining the set of entities that must agree to discard a subgraph means correlating the activity logs of nodes. FSC nodes record sufficient information in logs to ensure that such correlations can be achieved. The platform defines a stream available to anyone to assist in this process. A tool is also provided that can generate "investigation requests" and send them to a seed node. The flow notifies the node administrator that a decision is required, and sufficient information is passed to the node to attempt to persuade the administrator to participate (such as a signed court order). If the administrator accepts the request via the node browser, subsequent jumps in the transaction chain are returned. This tool semi-automatically crawls the network in such a way that it finds all actors that would be affected by the proposed rollback operation. The platform does not participate in determining what types of transaction rollbacks are legitimate, and provides only minimal support for implementing rollback operations beyond locating the parties that must agree. There are at least two strategies for modifying the ledger once the involved actors have been identified. One is to extend the transaction chain using transactions that simply correct the database so that it matches the expected reality. In order to make this approach possible, smart contracts must be written so that they can be modified arbitrarily outside of normal business logic when the submitted signatures reach a sufficient threshold. This strategy is simple and makes the most sense when the state contains a small number of parties, none of whom have any incentive to leave harmful information on the ledger. An asset state resulting from theft or fraud will involve participants who will resist all attempts to patch it in the above manner, because they can derive real-world benefits from the time between when the ledger is corrupted and before it is restored to its actual state. For this situation, a more complex method needs to be used, that is, all participants except the uncooperative participants agree to mark the relevant state as no longer consumed or has been spent. This is essentially a limited form of database rollback. # Risk assessment and decision-making As an innovative technology, blockchain is not only a disruptive breakthrough in core computer technology, but also an innovation in various industries. Therefore, the importance of risk management system is self-evident. The foundation adheres to the establishment of a risk-oriented and sustainable blockchain community. The Foundation will conduct ongoing risk management for the Foundation's operations. It includes a series of activities such as risk system establishment, risk assessment, and risk response. For major risks, the Foundation's strategic decision-making committee needs to discuss and make decisions. The Foundation will classify events based on their characteristics, such as the degree of impact, scope of impact, amount of tokens affected, and probability of occurrence, and make decisions based on priority. For high-priority events, relevant committees of the Foundation will be organized as soon as possible to make decisions. Nothing in this white paper constitutes legal, financial, business or tax advice, and you should consult your own legal, financial, business or other professional advisor before engaging in any activities related to this. Community staff, project R\&D team members, third-party R\&D organizations and service providers are not responsible for any direct or indirect damages and losses that may result from the use of this white paper. This white paper is for general information purposes only and does not constitute a prospectus, offer document, offer of securities, solicitation of investment or any offer to sell any product, item or asset (whether digital or otherwise). The following information may not be exhaustive and is not meant to have any element of contractual relevance. The white paper cannot guarantee the accuracy or completeness of the information, and does not guarantee or promise to provide a statement of the accuracy or completeness of the information. To the extent this whitepaper contains information obtained from third parties, the community and team have not independently verified the accuracy and completeness of such information. In addition, you need to understand that the surrounding environment and situations may change at any time, so this white paper may be out of date, and the community has no obligation to update or correct the content and documents related to this. No part of this white paper constitutes and will not constitute any offer by the community, distributors, or any sales team (as defined in this agreement), nor can the content stated in the white paper be relied upon for any contract or investment decision. Foundation. Nothing contained in this white paper constitutes a representation, promise or guarantee of future performance. By accessing and using this white paper or any content therein, you provide the community, its affiliates and your team with the following guarantees: In any decision to purchase Tokens, you have not relied on any statement in this white paper; You will voluntarily bear the costs and ensure compliance with all legal, regulatory requirements and restrictions applicable to you (as the case may be); ■ You acknowledge, understand and agree that Token may not have any value, does not guarantee or represent any value or circulation properties, and cannot be used for speculation-related investments; ■ Neither the community nor its affiliates nor team members are responsible or liable for the value, transferability, liquidity of Token, or any market in which FSC is provided through third parties or other means; ■ You acknowledge, understand and agree that you will not be eligible to purchase any Token qualifications: i. The sale of Tokens may be defined or interpreted as the sale of securities (however named) or investment products; ii. Countries and regions where contact and participation in the sale of Tokens are prohibited by law or where Tokens are prohibited by laws, policies, regulations, treaties or administrative regulations. The community and the team do not and do not intend to make any representations, warranties and commitments to any entity or individual, and hereby disclaim any responsibility (including but not limited to the accuracy of the content of this white paper and other materials published by any community, completeness, timeliness and reliability). To the maximum extent permitted by law, the community, related entities and service providers are not responsible for any use of the content of the white paper, related materials published by the community and related content presented through other forms (including but not limited to any errors or omissions) Liability for indirect, special, incidental, indirect or other losses arising from tort, contract disputes or other forms (including but not limited to any liability arising from any resulting breach of contract or negligence, any income and loss of profits and loss of use and data). Potential purchasers should carefully consider and evaluate all risks and uncertainties (including financial, legal and uncertain risks) associated with sales, communities, distributors and teams. # Disclaimer The information provided in this white paper is for community discussion only and is not legally binding. No one is obliged to enter into any contract or binding legal commitment regarding the acquisition of FSC. In addition, this white paper will not accept any virtual currency or other forms of payment. The Token purchase and sale agreement and the long-term continued holding of Tokens are subject to a set of independent terms or a purchase agreement containing relevant terms and conditions (as the case may be), which will be provided to you separately or can be obtained from the website. If there is any inconsistency between these Terms and Conditions and this Whitepaper, these Terms and Conditions shall prevail. Regulatory authorities have not reviewed or approved any of the information set out in this white paper and there are no laws, regulatory requirements and rules in any jurisdiction that require or will require doing so. The publication, distribution or dissemination of this white paper does not imply that applicable legal, regulatory requirements or rules have been fulfilled and complied with. This is just a conceptual white paper to describe the long-term development goals of FSC to be developed. This white paper may be modified or replaced from time to time. There is no obligation to update the white paper and provide the audience with other information beyond the scope of this white paper. All statements, press releases and publicly accessible statements contained in this white paper, as well as oral statements that may be made by the community and the FSC team, may constitute forward-looking statements (including related statements of intent and expectations regarding current market conditions, operating strategies and plans, financial conditions, specific regulations and risk management decision-making confidence and expectations). You are cautioned not to place undue reliance on these forward-looking statements, as these statements involve known and unknown risks, uncertainties and other factors, which may cause actual future results to differ materially from those described in these forward-looking statements. , at the same time, it should be noted that there is no independent third party to review and judge the reasonableness of these statements and assumptions. These forward-looking statements only apply as of the date shown in this white paper, and the community and the FSC team expressly disclaim any liability (whether express or implied) for the consequences or events arising from revisions to these forward-looking statements after that date. ). The use of any company or platform name or trademark herein (other than in connection with the Community or its affiliates) does not imply any association with or endorsement of these third-party platforms and companies. The specific companies and platforms mentioned in this white paper are for reference and illustration purposes only. # 介绍 探索 FON Chain 生态系统,做最好的去中心化web3。 FON 智能链是一种全新的公链。 FON 智能链依赖于一个由 21 个活跃验证者组成的系统，该系统具有权益证明 (APoS) 共识，可以支持较短的出块时间和较低的费用。质押最多的验证者候选者将成为验证者并产生区块。双签检测和其他罚没逻辑保证了安全性、稳定性和链的最终性。除了 21 个活跃的验证者之外，FSC 还将引入更多的验证者，例如另外 20 个不活跃的验证器，作为备份进入验证器集，这将被称为“候选者”。 候选人将在FSC Mainnet中产生障碍并收取汽油费，但比正式验证者组成的21套选举的机会要少得多。不可用的候选人也将被削减，尽管规模较小。预计将保持良好的动机，以便候选验证者愿意确保质量并帮助确保 FSC在极端情况下，如果活跃的 21 个验证者中的大多数受到攻击并离线，在创世区块中，团队设定了一个节点来保障公链的正常运行。 FON 智能链还支持与 EVM 兼容的智能合约和协议。由于对互操作性的原生支持，跨链传输和其他通信成为可能。 * **自主权区块链：**通过民选验证者提供安全性和安全性。 * **EVM-comp**支持所有现有的以太坊工具以及更快的最终性和更便宜的交易 * **可互操作:** 自带高效原生双链通信；针对需要快速流畅的用户体验的高性能 dApp 进行了优化。 * **分布式链上治理：** 权益证明（APoS）带来了去中心化和社区参与者。作为原生代币，FON 将作为智能合约执行的气体和用于质押的代币。 ### 跨链和多链的生态系统​ 从历史数据中吸取的重要教训是，“一条链”不能涵盖所有角度。在高峰期，FSC 的日活跃用户（DAU）超过 200 万，单个 GameFi 达到 100 万 DAU。这给网络本身及其支持基础设施（如 RPC/API 节点）带来了重大挑战。对于拥有海量用户群的 dApp，多链和跨链应该是解决方案。 FSC 核心团队坚信分区链和多链的未来，因为它可以维持对去中心化计算能力和存储不断增长的需求。这与业内许多其他区块链如 ETH2.0 以及 Polkadot、Cosmos 和 Avalanche 中的多链策略是一致的。 跨分片和跨链/多链互操作性将是 2022 年的关键话题。FSC 代币和开发者社区致力于实现 FSC 在去中心化区块链未来十字路口运营的愿景。具体来说，我们的目标是通过 FON 侧链和 FSC 分区链 (FPC) 基础设施层在 FSC 上实施新技术来实现这一目标。 ### Resources[​](https://docs.bnbchain.org/docs/learn/intro#resources) [White Paper](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvwkHQs7yXQT7ciUhgLaf%2Fuploads%2FgLwrylZIS4Cqh1iN3FYC%2FFON%20White%20Paper.pdf?alt=media\&token=720b884d-81ff-425a-a923-fc1dd0d1c0be) # 教程 在本节中，我们提供了 FON 智能链不同组件的使用教程。 #### 验证器 * [如何在FSC上搭建验证器](/zh_cn/develop/validator) 教程 #### 全节点 * [如何在FSC上运行全节点](/zh_cn/develop/validator/run) 教程 #### 跨链桥 * [如何使用FON智能链进行跨链](/zh_cn/bridgewallet/bridge)[ ](/zh_cn/bridgewallet/bridge)教程 #### 钱包 * [如何使用钱包链接FONChain](/zh_cn/bridgewallet/wallet)[ ](/zh_cn/bridgewallet/bridge)教程 * [如何通过第三方链接FONChain](/zh_cn/bridgewallet/wallettutorial)[ ](/zh_cn/bridgewallet/bridge)教程 # 安全审计报告 ### Beosin审计报告 [**Beosin**](#user-content-fn-1)[^1] 对 FON Smart Chain 审计报告，[查看审计报告](https://beosin.com/audits/FON-Smart-Chain_202209291625.pdf) {% embed url="" %} [^1]: # 社交和媒体 在这里您可以找到 **FONChain** 的官方社交媒体渠道和社区列表。 如果英语不是您的第一语言，我们也有许多非英语社区，期待您的加入！ ### 关注𝕏 *** ### 💬 电报 (Telegram) **官方电报群：** * 📣 公告频道（全球）**(** [**https://t.me/FonSmartChain**](https://t.me/FonSmartChain) **)** 英文交流群组 ([ ](https://t.me/rosswapofficial) ) 中文交流群组 ( ) {% hint style="danger" %} 管理员会在群里帮您解决问题，并不会私聊你。 所有主动私聊你的都是诈骗，会把你的钱包资产套路走。。 {% endhint %} {% hint style="danger" %} 管理员的聊天框右上角带有管理员标识。 请不要把你的私钥或者助记词分享给任何人、 或者填写任何表单！否则会造成不可逆的资产损失。 {% endhint %} # 跨链桥 通过跨链桥更方便使用FON Chain 万链互通 跨链转移代币的能力是一项基本需求。这允许用户将他们的资金从一个区块链网络转移到另一个区块链网络。牢记跨链支持的重要性，多个网络现在都有各自的“桥梁”来帮助轻松进行资金转移。以下是支持 FSC 与其他代币跨链转移的桥梁和交易所列表。 * HieSwap闪电跨链 * SWFT跨链协议 支持BNB智能链的跨链桥列表
类型 名称网站教程
多链HieSwap闪电跨链https://hieswap.com关联
多链代币SWFThttps://www.allchainbridge.com关联
# 钱包 通过第三方钱包更方便使用FON Chain ### 什么是钱包？ 加密钱包是用于传输和存储加密货币的设备或程序。加密钱包可以有不同的类型，例如纸钱包、硬件钱包和软件钱包。还有一些智能手机移动应用程序和计算机程序提供了一种用户友好的方式来创建和管理钱包。与加密货币一起，加密钱包存储一组加密密钥，用于发送、接收和追踪加密货币的所有权。 密钥对是加密派生的安全生成的私钥和公钥。私钥及其对应的公钥一起称为密钥对。钱包包含一个或多个密钥对的集合，并提供一些与它们交互的方法。任何加密钱包的安全性都取决于私钥的存储方式。 公钥被称为钱包的接收地址或简称为地址。钱包地址可以自由分享和展示。当另一方要向钱包发送一定数量的加密货币时，他们需要知道钱包的接收地址。根据区块链的实施，该地址还可用于查看有关钱包的某些信息，例如查看余额，但无法更改钱包的任何信息或提取任何原生币和代币。 为了将加密货币发送到另一个地址或对钱包进行任何更改，私钥用于对交易进行数字签名。重要的是要注意私钥绝不能共享，并且应始终安全保存。如果以任何方式获得对附加到钱包的私钥的访问权限，攻击者就可以提取所有包含的令牌。此外，如果钱包的私钥丢失，则任何已发送到或存储在该钱包地址中的代币都将永久丢失。 不同的钱包解决方案提供不同的密钥对安全方法，与密钥对交互以及签署交易以使用/花费代币。有些比其他的更容易使用，有些存储和备份私钥更安全。FON智能链支持多种钱包，让用户有权选择合适的钱包来满足他们所需的安全性和便利性。 如果您希望能够在币安智能链区块链上接收 FON 和其他支持的代币，您首先需要创建一个钱包并配置密钥管理。 ### 支持的钱包 * 支持FON链的钱包列表
钱包名称网站是否收录
Avewallethttps://ave.ai/download是
Bitget Wallethttps://web3.bitget.com是
TokenPockethttps://www.tokenpocket.pro快捷收录
MetaMaskhttps://metamask.io自定义添加
OKX Wallethttps://web3.okx.com自定义添加
Math Wallethttps://mathwallet.org自定义添加
# 密钥管理 本文是关于 FON智能链去中心化应用程序客户端密钥管理策略的指南 ### FON设置Web3 `web3.js`是一个 JavaScript 库，它允许我们的客户端应用程序与区块链对话。我们将 web3 配置为通过 Metamask 进行通信。 `web3.js`医生在[这里](https://web3js.readthedocs.io/en/v1.2.2/getting-started.html#adding-web3-js) ### 连接到 FSC网络 ``` // mainnet const web3 = new Web3('https://fsc-dataseed1.fonscan.io:443'); ``` ### 设置帐户 如果 web3 的安装和实例化成功，下面应该成功返回一个随机帐户： ``` const account = web3.eth.accounts.create(); ``` ### 恢复帐户 如果您备份了您的账户私钥，您可以使用它来恢复您的账户。 ``` const account = web3.eth.accounts.privateKeyToAccount("$private-key") ``` ### 完整示例 ``` const Web3 = require('web3'); async function main() { const web3 = new Web3('https://fsc-dataseed1.fonscan.io:443'); const loader = setupLoader({ provider: web3 }).web3; const account = web3.eth.accounts.create(); console.log(account); } ``` # 第三方钱包教程 FON 智能链提供广泛的第三方钱包支持，可用于发送/接收/购买/交换。下面我们提供了最受欢迎的钱包列表。 若钱包未正式收录FON智能链，支持自定义，也可进行自定义添加FON 智能链的网络参数 填写 FON Chain一些网络基础信息，请您填写一定要检查是否正确 ``` 网络名称：FON Chain RPC URL：目前官方公开的RPC https://fsc-dataseed1.fonscan.io https://fsc-dataseed2.fonscan.io https://fsc-dataseed3.fonscan.io https://fsc-dataseed4.fonscan.io 链ID：201022 货币符号：FON 区块链浏览器：https://fonscan.io ```
钱包教程链接
Ave.ai 使用FON Chain在 Ave.ai
TokenPocet使用FON Chain在 TokenPocet
Bitget Wallet使用FON Chain在 Bitget Wallet
Metamask使用 FON Chain在 Metamask
# Metamask 通过 Metamask 钱包使用FON Chain ## 1. 步骤一（打开官网） 使用谷歌浏览器进入MetaMask官网
## 2. 步骤二（添加插件） 通过谷歌添加，安装《MetaMas》插件，点击Add to Chrome
## 3. 步骤三（创建钱包） 安装完成《MetaMas》插件后，选择你要导入的方式 最新版本的MetaMas导入只支持助记词，请养成保存助记词的习惯。
## 4. 步骤四（添加网络） 导入或创建完成后，正式进入《MetaMas》钱包，选择添加网络，添加FON Chain基础信息
## 5. 步骤五(手动添加) 手动添加FON Chain网络，输入FON Chain（RPC相关信息）
## 6. 步骤六（网络参数） 填写 FON Chain一些网络基础信息，请您填写一定要检查是否正确 ``` 网络名称：FON Chain RPC URL：目前官方公开的RPC https://fsc-dataseed1.fonscan.io https://fsc-dataseed2.fonscan.io 链ID：201022 货币符号：FON 区块链浏览器：https://fonscan.io ```
## 7. 步骤七（完成操作） 添加以上就完成了通过《MetaMas》添加FON Chain网络的使用
{% hint style="danger" %} 温馨提示： 请您一定要妥善保管好，自己的助记词或私钥，以免造成资产损失。 {% endhint %} # Ave.ai 通过Ave.ai钱包使用FON Chain 通过 [Ave.ai官网](https://ave.ai) 下载 [Ave.ai钱包](https://ave.ai/download)，下载完成 进入Ave.ai App
2.进入Ave.ai App后，点击钱包，连接钱包进行创建
3.根据自己的使用情况，选择创建，或者通过私钥导入 目前Ave.ai，当前版本支持，创建，导入，观察钱包功能
4.设置钱包名称，设置密码，点击确认 请务必在安全的环境下抄写助记词进行验证
5.创建钱包后，点击切换FSC网络，点击选择FSC
6.点击+图标，选择FSC上的资产，热门单币和资产会自动加载
7.切换到FSC所有的交易列表，点击市场，选择FSC
8.切换到FSC上的Dapp专区，快捷进入到Dapp
{% hint style="danger" %} 温馨提示： 请您一定要妥善保管好，自己的助记词或私钥，以免造成资产损失。 {% endhint %} # TokenPocket 通过 TokenPocket 钱包使用FON Chain ## 步骤一（打开官网） 使用浏览器进入TokenPocket官网 [https://www.tokenpocket.pro](https://www.tokenpocket.pro/)
## 2. 步骤二（选择下载对应版本）
### 3.如何在TokenPocket创建 FON Smart Chain 公链？ 1、打开TokenPocket，点击右上角![](/files/zDrUFEupooBCVRauSaqW)添加钱包，在【选择网络】界面中点击最下方的【添加自定义网络】
2、打开自定义网络界面，点击右上角【便捷入口】，TokenPocket会针对热门的公链进行收录，通过便捷入口就可以很方便的搜索到自己需要添加的公链。 在搜索栏中填入FON，可以看到下方的搜索结果，点击准备添加。
3、核对信息后点击右下角的【保存】，即可添加成功。回到选择网络界面，下拉到最底部可以看到新添加的 FON Smart Chain 网络。
4、点击新增加的 FON Smart Chain 公链，可以选择【创建】或【导入】方式使用FSC钱包。
5、添加完 FON Smart Chain公链后，可以进行钱包地址同步，打开TokenPocket，点击【详情】，选择【钱包同步】，选择 FSC 公链同步后切换到Fon钱包即可。
# 共识引擎 尽管工作量证明（PoW）已被公认为实现去中心化网络的实用机制，但它对环境不友好，并且需要大量参与者来维护安全性。 以太坊和其他一些区块链网络，如[MATIC Bor](https://github.com/maticnetwork/bor)、[TOMOChain](https://tomochain.com/)、[GoChain](https://gochain.io/)、[xDAI](https://xdai.io/)，确实在不同的场景中使用[权威证明（PoA）](https://en.wikipedia.org/wiki/Proof_of_authority)或其变体，包括测试网和主网。PoA 为 51% 攻击提供了一些防御，提高了效率和对某些级别的拜占庭玩家（恶意或被黑客攻击）的容忍度。它可以作为选择基础的简单选择。 同时，PoA 协议最受诟病的地方在于它不像 PoW 那样去中心化，因为验证者，即轮流出块的节点，拥有所有权限，容易受到腐败和安全攻击。其他区块链，例如 EOS 和 Lisk，都引入了不同类型的[委托权益证明 (DPoS)](https://en.bitcoinwiki.org/wiki/DPoS)，以允许代币持有者投票并选举验证者集。它增加了权力下放并有利于社区治理。 FSC在此提出将DPoS和PoA结合起来进行共识，这样： 1. 块由一组有限的验证器生成 2. 验证者以 PoA 方式轮流出块，类似于[以太坊的 Clique](https://eips.ethereum.org/EIPS/eip-225)共识设计 3. 验证者集是根据基于抵押的治理选入和选出的 FSC 的共识协议实现了以下目标： 1. 阻塞时间短，主网上 3 秒。 2. 确认交易的最终性需要有限的时间，主网大约需要 45 秒。 3. 原生代币FON不存在通胀，区块奖励从交易手续费中收取，以FON支付。 4. 它与以太坊系统 100% 兼容。 5. 它允许现代权益证明区块链网络治理。 ### 验证者法定人数 在创世阶段，一些可信节点将作为初始验证者集运行。封锁开始后，任何人都可以竞争加入成为候选人来选举验证人。质押状态决定前 21 个最受质押的节点成为下一个验证者集，这样的选举将每 3 小时重复一次。 FON 是用于为 FSC 抵押的代币。 为了保持与以太坊的兼容性并可升级到未来要开发的共识协议，FSC 这些规则全部写入了创世合约。FSC上有一个专门用于 Dapp 的质押模块。 ### 帕利亚 共识引擎的实现被命名为**Parlia**，类似于[clique](https://ethereum-magicians.org/t/eip-225-clique-proof-of-authority-consensus-protocol/1853)。本文档将更多地关注差异而忽略共同的细节。 #### 轻客户端安全 验证者集更改发生在 (epoch+N/2) 个区块。（N 是 epoch 块之前验证器集的大小）。考虑到轻客户端的安全性，我们延迟 N/2 块让 validatorSet 发生变化。 每一个epoch块，验证器都会从合约中查询验证器集，并将其填充到块头的extra\_data字段中。全节点将根据合约中的验证器集对其进行验证。轻客户端将使用它作为下一个 epoch 块的 validatorSet，但是，它不能根据合约验证它，它必须相信 epoch 块的签名者。如果 epoch 块的签名者写入了错误的 extra\_data，轻客户端可能会转到错误的链上。如果我们延迟 N/2 个块让 validatorSet 发生变化，错误的 epoch 块将不会得到其他 N/2 个由其他验证器签名的后续块，这样轻客户端就不会受到这种攻击。 #### 系统交易 共识引擎可能会调用系统合约，这样的交易称为系统交易。系统交易由生产区块的验证者签名。对于见证节点，会根据其内在逻辑生成系统交易（不带签名），并与区块中的系统交易进行比对，然后再应用。 #### 强制退避 在 Clique 共识协议中，乱序验证者必须等待一段随机的时间才能封块。它在客户端节点软件中实现，并假设验证器将运行规范版本。然而，考虑到验证者在经济上会受到激励以尽快密封区块，验证者可能会运行节点软件的修改版本来忽略这种延迟。为防止验证者仓促封块，每个轮到的验证者都会获得一个指定的时间段来封块。任何出块时间较早的出块验证者产生的块都将被其他见证节点丢弃。 #### 通过临时审查 如果更新验证器的交易在 epoch 期间被发送到 FSC，那么验证器可能会审查交易并且不更改该 epoch 的验证器集。虽然如果没有其他 n/2 个验证者的帮助，一笔交易不可能永远被审查，但它可以延长当前验证者集的时间并获得一些奖励。一般来说，这个方案的概率可以通过与其他验证者串通来增加。这是一个相对良性的问题，一个块可能大约是 3 秒，一个纪元是 200 个块，即 20 分钟，因此验证器只能再延长 10 分钟。 ### 安全性和最终性 假设有超过 ½ \* N+1 个验证者是诚实的，基于 PoA 的网络通常可以安全和正确地工作。然而，在某些情况下，一定数量的拜占庭验证器仍可能设法攻击网络，例如通过[克隆攻击](https://arxiv.org/pdf/1902.10244.pdf)。为了与 FC 一样安全，鼓励 FSC 用户等到收到由超过 ⅔\*N+1 个不同验证者密封的块。这样，FSC 可以在与 FC 类似的安全级别上受到信任，并且可以容忍少于 ⅓ \* N 的拜占庭验证器。有 50 个验证者，如果出块时间为 3 秒，则 ⅔ \* N+1 个不同的验证者印章将需要 (⅔ \* 21+1) \*的时间段3 = 45 秒。FSC 的任何关键应用程序可能必须等待 ⅔ \* N+1 以确保相对安全的最终性。然而，除了这样的安排，FSC 确实引入了 Slashing 逻辑来惩罚拜占庭验证者的双重签名或不可用。这种 Slashing 逻辑将在很短的时间内暴露恶意验证者，并使“克隆攻击”非常难以执行或执行起来极其无益。有了这个增强，½ \* N+1 甚至更少的块就足以作为大多数交易的确认。 # RPC JSON-RPC 端点 ### RPC访问线路 {% hint style="success" %} {% endhint %} {% hint style="success" %} {% endhint %} {% hint style="success" %} {% endhint %} {% hint style="success" %} {% endhint %} {% hint style="success" %} {% endhint %} > ### FSC-Chain ID：201022 # FSC浏览器 FON 智能链 (FSC) 浏览器是一个图形用户界面，旨在让用户与区块链进行交互。通过该界面，用户可以浏览区块链上已添加的区块信息、区块链上发生的交易、钱包余额、FON信息。 FON Smart Chain (FSC) 为其主网提供浏览器。 ### 主网探索者 * FonScan1 - [https://fonscan.io](https://fonscan.io/) * FonScan2- # 运行全节点 ### 全节点功能 * 将完整的区块链历史存储在磁盘上，并可以回答来自网络的数据请求。 * 接收并验证新的区块和交易。 * 验证每个帐户的状态。 ### 支持平台 我们目前支持运行完整节点`Linux`。 ### 建议要求 #### 全节点 * VPS 运行最新版本的 Linux。 * **重要** 1T GB 可用磁盘空间、固态驱动器 (SSD)、gp3、8k IOPS、250MB/S 吞吐量、读取延迟 <1ms。（如果从快照/快速同步开始，则需要 NVMe SSD） * 8 核 CPU 和 16 GB 内存 (RAM)。 * 建议 AWS 上的 m5zn.3xlarge 实例类型，谷歌云上的 c2-standard-16。 * 上传/下载速度为每秒 5 兆字节的宽带互联网连接 #### 验证器 * VPS 运行最新版本的 Linux。 * **重要** 1T GB 可用磁盘空间、固态驱动器 (SSD)、gp3、8k IOPS、250MB/S 吞吐量、读取延迟 <1ms * 8 核 CPU 和 16 GB 内存 (RAM) * 建议 AWS 上的 m5zn.3xlarge 实例类型，或 Google 云上的 c2-standard-16。 * 上传/下载速度为每秒 10 兆字节的宽带互联网连接 #### 同步模式 * 快速同步 **默认**同步模式。通过下载整个状态数据库，首先请求标头，然后填写块体和收据来同步一个快速同步的全节点。一旦快速同步到达 FON智能链网络的最佳区块，它就会切换到全同步模式。 * 完全同步 从创世开始同步一个完整节点，验证所有块并执行所有事务。此模式比快速同步模式慢一点，但安全性更高。 ## 运行全节点 #### 从快照同步（推荐[）](https://docs.bnbchain.org/docs/validator/fullnode#sync-from-snapshot-recommended) [**从发布页面** ](https://github.com/FONSmartChain/FSC)下载预构建的二进制文件或按照以下说明进行操作 ### 1.下载二进制文件 ``` wget https://github.com/FONSmartChain/FSC/raw/master/geth sudo chmod +x geth ``` ### 2.下载创世区块 
wget https://github.com/FONSmartChain/FSC/raw/master/genesis.json
### 3.初始化创世区块 ``` ./geth init --datadir data genesis.json ``` ### 4.下载静态节点列表 ``` wget https://github.com/FONSmartChain/FSC/raw/master/static-nodes.json -O data/geth/static-nodes.json ``` ### 5.启动节点 ``` ./geth --datadir data --networkid 201022 \ --http --http.port 20102 --http.addr 0.0.0.0 --http.api "web3,eth,txpool,net" \ --port 20103 ``` # 验证器 ## 概述 FON 智能链是一种创新的解决方案，FON 智能链依赖于一个由 99 个验证者组成的系统，该系统具有权益证明 (APoS) 共识，可以支持较短的出块时间和较低的费用。抵押最多的验证者候选人将成为验证者并生产区块。双签检测和其他罚没逻辑保证了安全性、稳定性和链的最终性。 除了 21 个活跃的验证者之外，FSC 还将引入更多的验证者，例如另外 超21 个不活跃的验证者作为备份加入验证者集合，这些验证者将被称为“候选者”。 不可用的候选人也将被削减，但规模较小。预计将保持良好的动机，以便候选验证者愿意确保质量并帮助确保 FSC。 在极端情况下，如果 21 个活跃的验证者中的大多数受到攻击并离线，候选验证者可以向信标链报告陈旧的阻塞，恢复它并最终提议重新选举活跃的验证者集。 ### 什么是验证器？ FON Smart Chain 依赖于一组负责在区块链中提交新区块的验证者。这些验证者通过签署包含由每个验证者的私钥签名的加密签名的块来参与共识协议。验证者集由 FON 智能链上构建的质押模块确定，以每3个小时刷新一次竟选名次，来进行竞选21个有效验证人。 # 创建验证器 ### 创建挖矿账户 您需要先创建一个代表密钥对的帐户。使用以下命令创建一个新帐户并为该帐户设置密码： ``` geth account new --datadir ./data ``` 此命令将返回公共地址和私钥的路径。密钥文件的备份是必要的！ 如果您已经有一个帐户，请使用助记词来恢复它： ``` geth account import --datadir ./data ``` #### 成为验证者候选人 您需要使用 [**FSC Validator**](https://fscnode.fonscan.io/#/) 合约进行创建验证者，创建验证者需要质押9999枚FON 创建完成后，您需要创建者地址，先给自己进行投票，让自己进入到99名次中 验证者竞选以每3小时刷新一次竞选排名，从而竞选出块人资格。 # 运行验证器 ### 验证器硬件要求 * 运行最新版本的 Mac OS X 或 Linux 的 VPS。 * **重要**2T GB 可用磁盘空间、固态驱动器 (SSD)、gp3、8k IOPS、250MB/S 吞吐量、读取延迟 <1ms（如果以快照/快速同步启动，则需要 NVMe SSD） * 16 核 CPU 和 64 GB 内存 (RAM) * 建议在 AWS 上使用 m5zn.3xlarge 实例类型，或在 Google 云上使用 c2-standard-16。 * 上传/下载速度为每秒 10 兆字节的宽带互联网连接 ### 设置验证节点 #### 1.同步区块信息 按照此处的说明设置完整节点。 #### 启动验证节点 ！！！警告 请不要将您的 RPC 端点暴露给公共网络。 ``` ## generate the consensus key and input the password echo {your-password to the mining account} > password.txt geth --datadir data \ --networkid 201022 \ --nodiscover \ --syncmode full \ --password password.txt \ --allow-insecure-unlock \ --unlock {the address of your mining account} \ --miner.gasprice 150000000000 \ --mine \ --miner.threads 1 \ --miner.gaslimit 80000000 ``` #### 停止验证 **您可以通过在geth 控制台**中发送命令来停止挖掘新块 **使用geth attach ipc:path/to/geth.ipc**连接到你的验证节点 ``` miner.stop() ``` 要恢复验证， ``` miner.start() ``` # 在FONSCAN验证合同 **一步：**在FON智能链上部署你的合约 **第 2 步：**转到 [**FON SCAN**](https://fonscan.com/verified-contracts) 点击“验证并发布”
**第三步：**填写您的合同的正确信息
* 合约地址 * 您在 Remix 或其他编译器中选择的编译器类型 * 选择开源许可证类型 **第 4 步：** 输入 Solidity 合约代码 如果已启用，您需要为优化选择“是”。 构造函数参数是可选的。如果您的合约有，您可以转到[此页面](https://abi.hashex.org/#)生成编码的 ABI json。 ！！！信息 ``` The default FRC20 contract template does not have a constructor method ``` 单击“验证并发布”以完成此过程。现在你已经准备好了！ # 白皮书
* [**背景概述**](/zh_cn/develop/white-paper/background-overview) * [FON智能链简介](/zh_cn/develop/white-paper/background-overview/introduction) * [设计原则](/zh_cn/develop/white-paper/background-overview/design-principles) * [应用目标](/zh_cn/develop/white-paper/background-overview/application-target) * [落地优势](/zh_cn/develop/white-paper/background-overview/advantages-of-implementation) * [**生态板块概述**](/zh_cn/develop/white-paper/ecological-sector) * [RosSwap](/zh_cn/develop/white-paper/ecological-sector/rosswap) * [Time Farm](/zh_cn/develop/white-paper/ecological-sector/time-farm) * [HieSwap](/zh_cn/develop/white-paper/ecological-sector/hieswap) * [Myth NFT](/zh_cn/develop/white-paper/ecological-sector/myth-nft) * [**代币经济**](/zh_cn/develop/white-paper/token-economy) * [经济模型](/zh_cn/develop/white-paper/token-economy/economic-model) * [质押和治理](/zh_cn/develop/white-paper/token-economy/staking-and-governance) * [流通示例](/zh_cn/develop/white-paper/token-economy/circulation-example) * [**FSC技术体系**](/zh_cn/develop/white-paper/technology-system) * [权益证明](/zh_cn/develop/white-paper/technology-system/proof-of-stake) * [跨链机制](/zh_cn/develop/white-paper/technology-system/cross-chain-mechanism) * [中继器](/zh_cn/develop/white-paper/technology-system/repeater) * [硬分叉、规范与争议解决](/zh_cn/develop/white-paper/technology-system/hard-forks-specifications-and-dispute-resolution) * [**风险评估及决策**](/zh_cn/develop/white-paper/risk-assessment-and-decision-making) * [**免责声明**](/zh_cn/develop/white-paper/mian-ze-sheng-ming) # 背景概述 随着区块链技术的不断演进，公链已成为全球范围内竞争最为激烈的领域之一，公链作为区块链技术的基础设施，具有去中心化、高度安全性和可靠性、灵活性和可扩展性、社区化和生态建设以及创新和定制等优势，正在改变着传统经济和社会的发展模式。 如今，公链领域正呈现出两大显著趋势：一方面是越来越多的区块链技术应用于金融领域，如去中心化金融（DeFi）、数字资产交易等；另一方面是公链逐步实现更高的性能和扩展性，以应对不断增长的交易需求。然而，现有公链在面对这些挑战时，仍然存在着一系列问题。 在众多现有公链中，性能问题是最为突出的，以比特币和以太坊为代表的公链，在高交易负载情况下，交易确认时间延长、交易费用上涨等问题成为了制约因素。在这一背景下，FSC生态发展基金打造了FON智能链，基于区块链的“共识信任”机制与加密算法，用户场景内的每一次交易都被记录在区块链上，不依赖于第三方中介机构，完全公开透明可溯源，建立全民信任的生态系统体系，并实现高效共识、多应用场景，可拓展性，高性能、高安全性、高速接入、高效运营。 FON智能链是一个去中心化高效节能的生态公链，可编程智能合约无缝兼容以太坊网络，降低开发和迁移成本。此外，创建在FON智能链上的去中心化DApp可包含隐私拓展、流动性挖矿、DeFi理财、隐私Swap、借贷、跨链交易、NFT、社交、支付、娱乐、电商等多种应用方向。 FON智能链将建立点对点直接可靠的信任，在商业场景中去除中介的干扰，形成新的数字货币体系、支付方式、信用机制，打造高效率、低成本、更安全的价值生态系统链。 # FON智能链简介 ### **FON Smart Chain(简称FSC或FONChain智能链），FON 智能链是一种全新的公链。** FON 智能链依赖于一个由 21 个活跃验证者组成的系统，该系统具有权益证明 (APoS) 共识，可以支持较短的出块时间和较低的费用。质押最多的验证者候选者将成为验证者并产生区块。双签检测和其他罚没逻辑保证了安全性、稳定性和链的最终性。除了 21 个活跃的验证者之外，FSC 还将引入更多的验证者，例如另外 20 个不活跃的验证器，作为备份进入验证器集，这将被称为“候选者”。 候选人将在FSC Mainnet中产生障碍并收取燃料费，但比正式验证者组成的21套选举的机会要少得多。不可用的候选人也将被削减，尽管规模较小。预计将保持良好的动机，以便候选验证者愿意确保质量并帮助确保 FSC在极端情况下，如果活跃的 21 个验证者中的大多数受到攻击并离线，在创世区块中，团队设定了一个节点来保障公链的正常运行。 FON 智能链还支持与 EVM 兼容的智能合约和协议。由于对互操作性的原生支持，跨链传输和其他通信成为可能。 自主权区块链：通过民选验证者提供安全性和公正性。 EVM-comp支持所有现有的以太坊工具以及更快的最终性和更便宜的交易。 可互操作: 自带高效原生双链通信，针对需要快速流畅的用户体验的高性能 Dapp 进行了优化。 分布式链上治理： 权益证明（APoS）带来了去中心化和社区参与者。 作为原生代币，FON 将作为智能合约执行的气体和用于质押的代币。 ### **动机** FON Smart Chain智能链的创立和发展过程经历了众多挑战，FSC是一个由全球分布式自治社区主导的区块链生态系统，社区众多用户以共识DeFi去中心化为基础，从TRON网络到FSC网络经历了多年的DeFi共识沉淀，通过DAO治理投票联合打造一条属于自己独立运行、高速、高吞吐、服务型公链。 FSC自2022年10月22日上线，经历了一年的稳定网络出块，被称为：全球社区最活跃区块链(目前FON持币地址近180万个)、全球几乎完全去中心化的区块链(所有FON原生币100%流通，无增发、无预留)、也是全球增速最透明的公链。 ### 跨链和多链的生态系统​ 从历史数据中吸取的重要教训是，“一条链”不能涵盖所有角度。在高峰期，FSC 的日活跃用户（DAU）超过 200 万，单个 GameFi 达到 100 万 DAU。这给网络本身及其支持基础设施（如 RPC/API 节点）带来了重大挑战。对于拥有海量用户群的 Dapp，多链和跨链应该是解决方案。 FSC 核心团队坚信分区链和多链的未来，因为它可以维持对去中心化计算能力和存储不断增长的需求。这与业内许多其他区块链如 ETH2.0 以及 Polkadot、Cosmos 和 Avalanche 中的多链策略是一致的。 跨分片和跨链/多链互操作性将是近几年来的关键话题，FSC代币开发者和对应的社区致力于实现 FSC 在去中心化区块链未来十字路口运营的愿景。 # 设计原则 在FON智能链生态系统中构建独立运行的区块链系统，FON智能链并不会依赖其他任何网络。 ### FSC的设计遵循以下原则： #### 独立区块链： 从技术上讲，FSC 是一个独立的区块链，而不是Layer2 解决方案，大多数FSC基础技术和业务功能应该是自包含的，这样即使其他配套短暂停止，它也能正常运行。 #### 以太坊兼容： 第一个实用的、被广泛使用的智能合约平台是以太坊 。为了对接相对成熟的应用和社区，FSC 选择与现有的以太坊主网兼容。 这意味着大多数Dapp、生态系统组件和工具将与FSC兼容，不需要修改或只需要很小的更改；FSC 节点仅需要类似或稍高的硬件规范和操作技能就能运作。这一实现应为 FSC 和以太坊未来的版本继续兼容提供空间。 ### 基于权益质押的共识和链上管理的： 基于权益质押（APoS）的共识更环保，给社区治理提供更灵活的选择。可以预期的是，这种共识会比PoW共识有更好的性能，即出块时间短，交易处理容量高。 ### 代币经济学 FON智能链FON原生币总量为2600万，且不可增发。 FON智能链上线后，创世合约就已在Github开源地址： 1.初始团队销毁200万枚 2.创世团队持有80万枚 3.通过DEX以及生态机制和团队盈利陆续销毁了\~969,679 FON销毁地址：0x000000000000000000000000000000000000dEaD 当前FON数量为100%流通，FON原生币无预售和ICO，FON除团队外代币都已挖矿完成后全部流通上线。 # 应用目标 FON智能链的目标是利用自研公链技术并结合区块链技术特性，建设一个公平、公开的综合性应用体系。解决行业目前所面临的信任问题及公平问题，使整个竞争环境更加公平、公开、高效。 FSC的使命是希望能在区块链时代为全球商业和用户构建一个完整的价值生态，并希望这个生态能为用户的自由意志和个人价值，特别是时间价值提供保障。 各大平台正在建立商业世界的隔阂，正在分裂整个加密世界，正在变成⼀个又一个孤立的孤岛，各经济体之间的桥早已被无情的拆掉，不但如此，他们还筑起了⾼高的围墙。FSC希望能在区块链时代为全球用户提供更理想的生态环境，实现各独立生态之间的互通，FSC将在每个大陆之间架起桥梁，让大家从新的维度去认识这个由区块链构建起来的加密新世界。 FSC的设计初衷是构建一个多维度的公链系统，通过跨链技术，构建出一套完善的跨链方案搭载在FSC公链上，使用区块链技术产出的统一数字货币进行奖励： ■ 通证经济解决方案 ■ 多应用互通（数字货币交易、DeFi、NFT）解决方案 ■ 数字资产发行与流通生态体系 ■ 支付生态互通解决方案 当FSC的参与者作出了对FSC的贡献，根据贡献机制的计算，我们为其提供相应的合理回报。而作为商业应用级区块链解决方案，第三方商业机构的生态构建和转型升级问题也可通过FSC的应用得到解决。 FSC将彻底重塑现有互联网的运营模式，将经济激励系统本身变为能够在系统内循环的体系，创造一个完全去中心化互联网价值传输生态系统，同时也是个完全开放的社区生态系统，超越国界，让每一位参与者都能获得相应的价值体现。 # 落地优势 **得益于持续发展与创新的区块链技术、广泛的商业应用、精细化治理的优势，FSC在以下方面具备竞争力：** **技术** FSC具有十分成熟且强大的技术支撑，在区块链底层、加密通讯、数学、Web3、信息技术等多个领域积累了丰富的行业与技术经验，在区块链技术开发和应用方面取得了业界领先的突破。 **行业资源** FSC团队汇聚了多行业、多年实际运营经验、且对行业发展有深刻见解的资深人士。并且，FSC团队将与目标行业的顶级领头企业签署战略合作协议，将会为FSC切入应用提供强有力的支持，以此来真正推动FSC接入更多项目和开发者。 **商业治理** 与一般公链不同，FON智能链拥有对目标行业清晰且明确的战略规划，更为专注与专业的借助区块链技术的分布式去中心化、不可篡改和加密安全性及点对点传输价值的特性，针对目标行业进行渗透并快速取得市场份额。 **资金管理** FSC的资金管理将严格遵守公平、公正、公开的原则，并以FSC平台的发展为首要目的。 FSC团队专项保管且确保资金的安全性及可持续性。 FSC公链和FSC生态发展基金会所有资金使用情况将会定期向所有投资者披露，以保证资金使用的公开性。 **发展空间** FSC的目标行业均为万亿级别的区块链基础设施和加密市场，开发团队通过拟定完善的治理架构，对一般议事、代码管理、财务管理、薪酬管理和特权操作范围等事务进行有效管理，以确保可持续性发展。 FSC完美的继承了传统区块链生态系统技术的特性与优势，并解决了当前区块链的技术瓶颈，真正意义上将区块链与商业应用结合。并且，FSC大力且持续投入以区块链技术为代表的商业科技的研发和创新，将其运用于提升传统行业的价值以及促进区块链技术在各行各业中落地应用的蓬勃发展，辅以清晰明确的战略发展方向，以打造未来互利共赢的区块链公链生态系统。 # 生态板块概述 FON Smart Chain 生态系统是一个全面的去中心化平台，旨在通过利用创新的区块链技术为个人和组织提供支持， 该生态系统非常注重速度、可扩展性和安全性，旨在彻底改变企业运营和个人交易的方式，为广泛的应用程序提供了坚实的基础，包括 DeFi、供应链管理、游戏等。 **FON Smart Chain生态系统的核心是：FON和Roselle。** **FON是FON Smart Chain的原生币** 用来激励用户、第三方合作者参与生态建设等行为所发放的具有可兑换FON智能链内部价值资源和权益的代币。同时，FON智能链作为一种融合多形态数字资产的底层基础设施，可以通过金融智能合约衍生出更多其他的智能资产。 **Roselle是FSC的第一个标杆生态、万倍生态** 它的经济模型具有分散性、稀缺性及流通性、应用性、为用户提供质押奖励、参与生态系统成长等多种福利。 Roselle 的设计是安全高效的交换媒介，支撑所有交易生态系统。 **FON Smart Chain 目前已经正式上线应用的产品与生态板块：** **RosSwap：**RosSwap 是基于FON Smart Chain（简称FSC）公链，首个全新的DEX- RosSwap。 **Time Farm Gamefi：**Time Farm是一款基于FON智能链上运行的去中心化区块链游戏。 **HieSwap：**由RosSwap实验室投资的跨链协议HieSwap正式接入多个公链上线，目前该协议已实现FONChain 、BNBChain、HECO、Ethereum、OKXChain、Polygon和TRON七条链之间的跨链转换。 **神话NFT：**神话NFT卡分为四种稀有度类型，分别是：创世，经典，稀有，神话四大稀有度主类目。 远古至今的文明作为设计的每张唯一的NFT是获得股权权益分红来源。 # RosSwap RosSwap 是基于FON Smart Chain（简称FSC）公链，首个全新的DEX,RosSwap 致力于为您最大化利用虚拟货币资产！ RosSwap提供了更高的安全性、更方便快捷的交易方式、更公开透明的链上活动,进行交易后的Token也可在TokenPocket、MetaMask或其他EVM主流钱包上进行代币管理。 ### 公开透明 RosSwap 在开源软件上构造，网站和所有的智能合约都是公开的，以便最大化透明度，RosSwap的智能合约均已在 FonScan 上验证源码。 ### RosSwap的优势 团队汇聚了区块链、金融和技术领域的顶尖人才，拥有丰富的行业经验。致力于为用户提供创新的去中心化交易体验，保障交易过程的安全和可靠性。平台不仅注重技术创新，还积极探索和采纳行业最佳实践，为用户提供更加稳定和安全的交易环境。 ### 低手续费 RosSwap 在FON智能链上运行，对比以太坊或比特币以及币安智能链，FON智能链拥有低廉的交易成本。RosSwap 的交易手续费也远比其他顶级去中心化交易所低。所以，对您来说，这绝对是一箭双雕。 ### 去中心化 直接使用您的钱包 App 开始交易。 不同于币安或 Coinbase 等中心化交易所，RosSwap 在交易时不会持有您的资金：您对自己的加密货币有 100% 的所有权。 ### RosSwap产品股权化 随着交易量增加，DEX产生了一定的手续费收益 我们并不会将这份收益全部归到团队手中 我们将DEX产生的部分收益打包成股权化来分配给参与股权的用户 根据您自身的需求，来选择是否要参与这款股权化的产品 Rosswap产品股权，将根据Rosswap实际全产品的盈收决定 在产品认购股权期间，您有一定的思考（犹豫期）可以灵活的参与和取回 ### 产品股权根据官方的公布消息，分为三款股权奖励 1.DEX盈利以USDT作为结算单位，以质押FON为参与股权 2.为RosSwap提供流动性，质押获得多元化代币奖励 3.质押神话NFT获得多种组合延伸品收益 ### SWAP 功能和用户体验 提供创新的去中心化交易功能，包括LP流动性、农场池等。用户可以轻松将资产存入流动性池，并获得权益代币收益。平台界面简洁直观，适合各类区块链交易者，无论是初学者还是专业交易专家，都能享受到便捷的交易体验。 RosSwap将以FSC生态创造一个融合交易、治理、钱包和创意的开放数字平台，聚集全球社区的力量，推动FSC生态的不断前进和壮大。 RosSwap不仅极大的丰富了区块链生态,且必将在DEFI发展史上留下里程碑式的意义。 RosSwap将永久秉持着合作、创新、多样性和可持续性的核心价值观，不断探索创新可能性，引领数字金融的新未来。 # Time Farm Time Farm（时光农场）是一款基于FON智能链上运行的一款去中心化区块链游戏，作为目前较火热的一款GameFI链游。 Time Farm不仅结合了NFT与区块链挖矿，还融入了当前比较火热的Farm元素，使整个游戏内容更加丰富。 ### Time Farm技术特性 Time Farm是基于Web3底层公链技术上的链上游戏。 数据全程上链，节点区块打包，公开透明。 Time Farm在链游农民世界的基础上进行了创新与改革， 做到公平公正公开。 ### Time Farm的亮点： 1、四种资源进出口代币均为Roselle，解决游戏代币不断增发的痛点，游戏中的资源肉、木、石对标黄金，黄金对标Roselle。 2、所有资源零预挖，一切从零开始，参与者都在同一起跑线，保证公平公正。 3、抽盲盒双签随机数，杜绝了任何人抢先高级装备的可能性，保证公平公开。 4、盲盒4200个永不增发，参与者必须自行合成装备，保证游戏的永续经营。 5、游戏集趣味性、关联性、循环性于一身，相辅相成、环环相扣。在GAMEFI 行业具有竞争力！ 6、 游戏代币权限丢弃，打入黑洞。肉、木、石、金代币数量分别 为40W 、 37W、30W、118W，永不增发，保证游戏代币资源市 场自动平衡原则。 7、每天8小时、12小时、24小时或48小时点一次就行，不用时时盯着手机去玩， 省时省力又赚钱。 8、NFT交易市场在AVE的FSC专区上线，装备可以随时交易，更具吸引力。TIMEFARM是AVE的首创NFT板块，AVE在币圈沉淀多年，拥有众多币圈用户，当游戏的价值越来越大，很多流量都会进来。 9、游戏资源变现代币，有5-12%的交易费用，将其打包成理财产品，其中30%分给Roselle股权质押者。 ### Time Farm杠杆逻辑 #### 1、链游是为洛神赋能，也是整个社区布道的工具： 初期装备是通过百万级的盲盒公平抢购的，抢到的人都赚到。一开始大家都没弄懂游戏的逻辑，好多人不去抢，后面赶紧买洛，换资源、合装备，也赚到了。这就是玩赚布道。 #### 2、三个杠杆逻辑 第一道杠杆；无论你合什么装备，无论你的本金是多少，你的产出收益每天都有，收益持续稳定。 第二道杠杆：当你产出的资源以后，你可以换成Roselle，而Roselle是FSC的第一个标杆、万倍生态，通过各种赋能和布道，Roselle上涨，你又赚钱，并且随时变现。 第三道杠杆：哪一天，赚够了，不玩了， 你随时可以去NFT交易市场挂出你想要的价格进行交易，最后你的装备卖出回本甚至更高价值。 #### 3、通过游戏，你不但赚了免费产出的资源，又得到洛神上涨带来的红利，还可以高价卖出你的装备NFT，投资一次，赚三次，这就是杠杆逻辑。通过杠杆逻辑，你会发现，赚钱原来这么容易的。链游Time Farm创奇迹！ Time Farm（时光农场)的出现则打破了现有区块链游戏的瓶颈和传统游戏开发的商业逻辑，将游戏收益和价值还给玩家，以颠覆传统游戏模式的全新玩法，结合区块链技术与理念，更好地保障了玩家利益，让玩家既能享受游戏的乐趣，又能从中获取收益，最终实现平台与玩家共赢局面。 # HieSwap 金钱永不眠，而是永远流向更高效的地方，2022年初，HieSwap创始团队进入DeFi领域时，惊奇地发现跨链交易居然如此繁琐与低效。 于是团队打造了HieSwap——将区块链跨链交易时长降低到3秒，这是行业首次将跨链交易时长缩短至秒级！这是里程碑式的突破，是继Uniswap AMM机制后，DeFi行业里又一重大基础设施变革，这将改变跨链交易的效率和未来的格局。 HieSwap独创的跨链技术，不仅速度快，而且超低的手续费，安全地让你的资产在各链中自由流通。 HieSwap还有一个特别让人欣慰的是跨链兑换公链币，一次性解决Gas费的问题，不再需要手动往对应链上转入手续费。 HieSwap，由RosSwap实验室投资的跨链协议HieSwap正式接入多个公链上线， 通过HieSwap跨链协议，用户可以在低交易费用、低滑点的环境下完成不同链之间的资产转移。 据悉，HieSwap上的交易时间最快可在3秒完成，比市面上其他同类型跨链方案的交易时间快15倍。 此外，HieSwap 多链之间稳定币兑换，具备每个链充足的流动性，有效降低了跨链用户的滑点风险，未来将接入更多链之间的聚合交易，将支持跨链之间兑换代币，给用户多重选择。 跨链原理和机制 HieSwap是一家部署在多条公链（目前支持FSC 、BSC、Heco、Oec、TRON、Polygon 和 ETH七条链）的去中心化交易平台。具备安全、交易费用低、速度快等特征，集跨链和聚合交易为一体，致力于让所有用户可以享受超低的费用与较低的滑点完成单链或双链间资产的兑换。
### HieSwap优点 #### 1. 安全 这是最基本的保障，HieSwap从创建之初就考虑到了安全保障，通过独特的技术，确保用户在使用中不会遇到安全问题。 #### 2. 超低费用 为您节约费用是我们的希望。在HieSwap，您仅仅需要支付较低的跨链手续费，即可快速、安全地完成跨链交易。Gas fee和目标链交易手续费将由对应的链收取。 #### 3. 快如闪电 快，是我们创立这个平台的初衷也是我们的目标。在瞬息万变的区块链，时间意味着效率，也意味着金钱。我们通过独创的跨链技术，将跨链交易从之前的3分钟以上，提升到9秒以内。跨链交易从此进入秒级时代。 DeFi创新给区块链带来了新的活力，促进了去中心化交易所（DEX）诞生，并得到用户的认可。然而，跨链交易的不便捷和时间长给用户带来非常糟糕的体验。在瞬息万变的区块链市场，时间就是金钱，因为超长的交易时间给用户带来了巨大的经济损失。 HieSwap运用独创的技术，把区块链跨链交易从之前的数分钟降至秒级，最快可达3秒，对跨链交易仅收取低额的交易费，同时确保安全性，这给用户带来极大便利。 让用户自由流动资产是我们使命，让你的钱永不眠。 # Myth NFT 神话NFT卡分为四种稀有度类型 分别是：创世，经典，稀有，神话 四大稀有度主类目 远古至今的文明作为设计的每张唯一的NFT 神话NFT总量设计为2万张。 ### 设计元素构造： 以四大稀有度稀有度设 #### 创世四个特征主题共10222张 创世：蚩尤2555张，伏羲2555张，盘古2555张，玄女2555张 #### 经典分为三个特征和五个特征共8600张 经典三个特征：星际1500张，魔法1500张，黑暗1300张 经典五个特征：大王800张，小王800张，J900张，Q900张，K900张 #### 稀有分为两个特征和六个特征共998张 稀有两个特征： 圣经（加百列83张，撒旦83张，上帝83张）和奥林匹斯神（波塞冬83张，哈迪斯83张，宙斯84张） 稀有六个特征：春85张，夏85张，秋85张，冬85张，日80张，月79张 #### 神话分为一个特征和七个特征182张 一个特征：西王母91张 七个特征：女娲13张，洛神13张，嫦娥13张，羲和13张，织女13张，精卫13张，嫘祖13张 ### NTF铸造获得股权权益分红来源 #### 股权权益奖励一 FONCHAIN全网出块奖励，产生每一笔Gas费 这些将被以股权奖励到神话NFT合约作为分红奖励 全网产生Gas的10%奖励至神话NFT质押用户 #### 股权权益奖励二 Rosswap产生的全网DEX每一笔交易手续费 这些将被以股权奖励到神话NFT合约作为分红奖励 全网产生手续费的10%奖励至神话NFT质押用户 #### 股权权益奖励三 NFT交易市场全网产生的NFT每一笔交易手续费 这些将被以股权奖励到神话NFT合约作为分红奖励 全网产生手续费的10%奖励至神话NFT质押用户 ### 股权质押周期 参与神话NFT股权权益的流动性，都将有90天的顺延质押期 在质押后，你将在90天后可取回您的流动性故此您将不在获得股权权益分红 在已参与股权权益中，您可以继续参与，参与当前的流动性将会以最后一次参与区块顺延90天 ### 股权权益分红实质性 股权权益，将在每月20日进行对股权权益分红合约中 进行100%分配 你在股权权益分红前参与，都将会获得股权权益分红 股权权益分红比例 创世：49% 经典：43% 稀有：6% 神话：2% ### 注意事项 · 铸造将四种类型稀有度，创世，经典，稀有，神话 · 铸造成本，会存在一定的浮动，详情查看铸造页面 · 奖励三大权益：FONCHAIN区块奖励，Rosswap收益，NFT交易平台收益 · 奖励将于每月发放奖励，未质押将无法获得奖励 # 代币经济 FON原生币与FON智能链底层的价值、激励、治理与安全有着深刻逻辑关联，体现了FON的价值特性。 ■ 从价值上看，FON凝聚了“信任价值”和“共识价值”的载体； ■ 从激励上看，FON是激励网络中“记账人”的参与的经济奖励； ■ 从治理上看，FON原生币是参与FON智能链网络的权益凭证； ■ 从安全上看，价值激励的存在，提升了FON智能链的网络安全性。 FON将在FON智能链上运行，就像ETH在以太坊上运行一样，因此，它是FON智能链的“原生币”。这意味着，除了FON用于支付FON智能链的大部分费用外，还将用于： ■ 支付“费用”在FON智能链上部署智能合约 ■ 质押选定的FON智能链验证人，获得相应奖励 # 经济模型 FON智能链将发行FON公链币，FON是激励用户、第三方合作者参与生态建设等行为所发放的具有可兑换FON智能链内部价值资源和权益的代币。同时FON智能链作为一种融合多形态数字资产的底层基础设施，可以通过金融智能合约衍生出更多其他的智能资产，未来FSC公链会将通过更多创新模式驱动FON的价值增长。 ### FON经济模型 Fonvity （FON） Smart Chain Explorer 总量原生FON代币2600万枚 节点前21名获得节点出块奖励 FON Smart Chain用于有效治理提案，来丰富生态的健康发展 创建节点需要创建者，质押9999枚FON来进行创建 最大联盟节点为99名，超出后不可创建 前21名节点为核心节点可在对治理直接发起核心提案 创建节点者可随时退出联盟节点，同时9999枚FON也随之退回 节点竞选方式，通过FON质押进行对节点的投票 节点每三个小时刷新一次排名 FON在FSC上运行的方式与ETH在以太坊上运行的方式相同，因此它是FSC“原生代币”。 这意味着FON 除了可以在FON智能链和 DEX上 被用来支付大部分手续费用之外，FON 也将用于： 1.支付在 FSC上部署智能合约的手续费 2.对选定的 FSC 验证人进行权益质押，并获得相应的奖励 3.执行跨链，交易等操作，例如 FSC 转账代币资产 ### Roselle经济模型 #### 简介 Roselle是RosSwap以及NFT交易市场的平台token，是具备产品支撑的价值token，Roselle同时也是FSC的第一个标杆生态、万倍生态。它的经济模型具有分散性、稀缺性及流通性、应用性、为用户提供质押奖励、参与生态系统成长等多种福利。 Roselle 的设计是安全高效的交换媒介，支撑所有交易生态系统。 #### 由来 通过多种质押物开采完成 **• Wfon-Usdt LP 质押开采** **• NFT 质押开采** **• NFTs 质押开采** **• Wfon原生币 质押开采** #### 总量 **210万枚** 挖矿周期：5184000 区块开采结束 #### 机制细则 交易费率 • 买入费率：3% • 卖出费率：3% • 转账费率：3% #### 发放条件 产生的费率会先进入到Roselle代币合约暂存 当累计完成10枚Roselle会被合约自动执行 • 37%的Roselle流动性兑换为WFON • 62%的Roselle将会被燃烧 （ [燃烧通缩地址查看](https://fonscan.io/token/0xf75f541F2B12F5647DeEa400957E1B8f7388a390/token-holders) ） • 1%的Roselle将会添加至Roselle-Fon流动池 #### Roselle产生交易奖励分配方式 奖励分配比例：60%用于分配到市场，40%将转入黑洞来销毁FON 60%的奖励，将会累计之（价值股权系统）以股权分红的方式进行分配 #### 生态发展 生态发展基金 23%生态将更好的运营和建设Roselle ### WFON币是什么？ WFON 是FON智能链上与FON价格挂钩的 FRC-20 代币。 WFON是FON智能链上与FON价格(1:1)挂钩的FRC-20 代币。 虽然FON智能链的原生代币FON 可以用来支付汽油费，但WFON 不能。 但WFON的用途比FON更广泛，在去中心化金融(DeFi)生态系统中变得非常流行。 FON智能链网络中的几乎所有钱包都将支持WFON。 包装FSC(FON)是一种与FSC(FON)挂钩的代币。包装FON币适用于支持FRC-20代币的众多平台与去中心化应用程序。虽然(FON币)可用于支付网络交易手续费，但其功能与FRC-20代币(WFON币)有所不同。 您可以通过包装过程轻松地将FON币转换为包装FON币。您也可以随时将包装FON币换回FON币。包装与去包装都遵循 1:1 的比率，即除了交易手续费之外，没有额外费用。 通过与包装FON币智能合约交互，您可以手动包装FON币，智能合约将存储您的FON币并返还等额包装FON币。FON智能链的去中心化金融(DeFi) 生态系统相当庞大，包装FON币的使用为质押投资提供了更多机会。 #### 我们为什么需要包装FON币？ 起初，令人困惑的一点是：为什么存在像包装FON币这样的代币，FON区块链不是已经有了FON币吗？ 首先需要了解的是，FON上的每种代币在技术上并非都相似。该网络允许开发人员为加密货币创建新规则与新标准。 FRC-721形式就是一个例子，它为我们提供了非同质化代币 (NFT)。这些都与FON币或FRC-20代币非常不同。开发人员在创建这些数字资产时有很大的自定义空间。因此，虽然(FON币)可用于支付FON智能链上的燃料费，但FON币无法在所有去中心化应用程序中使用。 如今，大多数DeFi 去中心化应用程序都接受FRC-20代币用于投资与质押。如果想将(FON币)注入流动性资金池或将其用作抵押品，那么在FRC-20版本中使用(WFON币)会容易得多。这提供了整个区块链的最大兼容性，并节省了开发新智能合约的时间。 # 质押和治理 ### 权益质押与链上治理 APoS实现了去中心化式的社区治理。 你可以从其他网络中看到类似的想法，特别是 Cosmos 和 EOS 。 其核心逻辑可概括如下。 1\. 代币持有者，包括验证人，可以将他们的代币 “锁定”到权益质押中。 代币持有者可以将他们的代币委托给任何验证人或一个验证人候选对象。 之后他们还可以重新选择不同的验证人或候选对象来对他们的代币进行委托。 2\. 所有验证人候选对象都将按其获得委托代币的数量进行排序，排名前列的将成为真正的验证人。 3\. 验证人和委托人可以随时通过验证人权益解除质押。 ### FSC权益质押 理想情况下，这样的权益质押和奖励发放逻辑应该包含在区块链中，并在产生新区块时自动执行。与FON智能链一样采用Tendermint共识库的Cosmos Hub就是这样工作的。 FSC想要尽可能地与以太坊保持兼容，在其上直接实现APoS是一个巨大的挑战和压力。特别是考虑到以太坊本身可能在短时间（或更长时间）内迁移到PoS共识协议时，尤其如此。为了保持以太坊的兼容性我们在FSC的权益质押逻辑： 1\. 质押币是 FON，这是因为它是FSC上的原生币。 2\. 在FSC的权益质押和委托行为,FSC 验证人集由它的权益质押和委托逻辑来决定，在FSC上构建的权益质押模块FSC上的奖励分配发生在每3小时。 FON 是FSC权益质押的通证。 为了保持与以太坊共识协议（包括即将到来的升级）的兼容性，FSC 选择独立的权益质押管理。 在 FSC权益质押的模块。 它将接受FON 持有者的FSC权益质押，并计算出权益质押最多节点集。 每次3小时 时，刷新出块人排名，通知 FSC 更新其验证人集合。 在生成新的区块前，现有的FSC验证人定期检查是否有“ValidatorSetUpdate”消息转发到FSC 。 如果有，它们将在一段高度后（即预定义的区块间隔）之后更新验证人集合。 例如，如果 FSC 每 5 秒生成一个区块且检查周期是 240 个区块，那么当前的验证人集合将在 1200 秒（20 分钟）内检查并更新下一周期的验证人集。 ### 奖励 验证人集更新和奖励分配都发生在每3小时 。这样做可以更好的让FSC网络验证人更加健康，同时也可以让验证人之间更加的活跃。发放奖励将直接发放给验证人地址。 # 流通示例 ### 未来，FSC的流通价值体现在以下几个方面： #### 生态流通 在FON智能链基础上，将衍生出众多应用，比如挖矿钱包、DEX交易所、区块链支付等，而FON及其链上所属代币则可实现与所有数字货币的兑换，支持生态中各环节流通及支付，如收付款、转账、法币交易、充币、提币、上币投票、STO网关、配币、借贷、公益、游戏、商城等所有流通交易均以FON代币服务。以及与全球各国法币结算。 除了FON智能链生态体系内的流通外，还将在基于公链技术开发的第三方应用内进行流通，并且作为唯一价值通证存在。这将加速FON及其链上所属代币的流通，为稀缺的FON增加更多流通价值属性，拉高整体价值和价格。 #### 2通用性方面 FON智能链能适应多样化的业务需求，满足跨业务链条上的数据共享，这意味着FON智能链对数据的记录方式有足够的通用和标准，能表示各种结构化和非结构化的信息，并能够满足随着业务范围拓展所需的跨链要求。而这就为FON代币的通用性提供了价值基础。让FON及其链上所属代币能更加从容的流通于世界各地的各个行业和各个场景之中。 # FSC技术体系 #### FSC将为第三方项目区块链底层API，实现应用场景对接，实现数字资产叠加，从而为解决行业存在的相关现实问题。为了实现这一愿景，FSC已经在底层设计及顶层应用采用做出来相应的布局。 #### 秒级快速交易验证 通过对签名算法、账本结构、数据操作、序列化、共识机制、消息扩散等关键环节的优化，FSC将以实现秒级的快速交易验证。满足绝大部分区块链应用下金融场景的用户体验。 #### 海量金融数据的存储 区块链复式的记账模式，在系统不断的运用，积累了大量的数据，造成运行速度下降，FSC将会实现分离存储、分表存储机制，实现数据海量存储。 #### 交易吞吐量的提升 区块链的本质是一种分布式共享记账的技术，其分布式特征主要体现在分布式一致性而非分布式并发处理。为保证数据的一致性，防止拜占庭将军问题，某些特定环节只能串行执行，而无法并行。通过长期的测试与优化实践，FSC的处理性会进一步大幅提高交易吞吐量。 #### 节点数据快速同步 FSC将研发镜像机制，可以定期对本地账本制作镜像，实现便利的回滚机制，在统一共识下，可以指定镜像标签进行回滚。同时，缩短新加节点加入运转的周期，仅需同步最新镜像及少量近期交易集合，即可融入网络并参与共识验证。 #### 数据权限控制策略 FSC提供数据信息写入与读取两类权限控制策略。数据信息写入权限，同一账户下设置多个使用用户，并针对不同的操作设置相应的权限，满足多方签名控制的 使用场景。数据信息读取权限，用户可以授予和撤回单用户或用户组对数据的操 作权限，用户组可以由用户灵活配置。数据包括用户账户信息，交易信息等，粒度可以细化到交易或账户的各属性字段。 #### 多元的拓展性开发 FSC的区块链结构，能够满足不同业务领域的需求，提高系统的可扩展能力和维护效率。即可用于标记资产和资产转移，也可提供不可篡改的多维事件记录，还可以用于溯源以跟踪金融资产的流通过程。 #### 多重隐私保护 为了方便用户使用FSC产品服务，除了传统的客户端生成和保存的机制，FSC还提供网络托管存取和私钥硬件存取(U-key)两种方案。网络托管存取，即把用户名和密码通过特定算法映射成私钥并在服务端进行存储。服务器端存储的私钥均为加密数据，私钥仅能在用户端解密；硬件私钥是为了满足金融行业的使用需求。 同时，提供多重隐私保护功能。首先，FSC底层提供同态加密方式，用户所有数据均加密存储，仅用户本身可见。其次，提供加密中间件服务，用户可根据业务需要进行选择。最后，上层应用可以在录入时对数据进行加密处理，FSC负责对用户生成的加密数据进行写入和读取。 #### 可视化运维支持 FSC将提供运维管理所需的可视化工具。FSC节点上部署的系统监控服务：支持业务(区块、交易、合约、共识等)、网络(组网、时延、吞吐量等)、系统层面(CPU、内存、磁盘等)的数据信息监控。同时，提供完备的日志、告警与通知机制，便于金融商用系统的维护。 # 权益证明 ### 基于权益的权威证明 (Authority Proof Of Staked ) 尽管工作量证明（PoW）已被证明为实现去中心化网络的实用方案，但它对环境并不友好，而且还需要大量参与者来维护网络安全。 以太坊及一些其他网络，如 MATIC Bor、TOMOChain、GoChain、xDAI在不同的场景中使用权威证明（PoA）或其变体，包括测试网络和主网。PoA 为 51%的攻击提供了防御，更有效的防止一部分拜占庭节点作恶。 选用PoA作为底层共识是理想的选项之一。 同时，PoA 协议因不如PoW去中心化而被批评，因为验证人，即轮流生成块的节点，拥有极大的权力，并且容易产生腐败和遭受安全攻击。 其他区块链, 如 EOS, 引入了不同类型的委托权益证明（DPoS），允许代币持有者投票选举验证人节点。 它让网络更加去中心化，有利于社区管理。 受以上启发，FSC 将 DPoS 和 PoA 结合以达成共识，采用的方案为： 1\. 区块是由有限数量的验证人生成的 2\. 验证人轮流以 PoA 方式生成区块，类似于以太坊的Clique共识引擎 3\. 验证人集合是基于权益质押的链上治理选出和淘汰 ### 验证人节点法定人数 在网络启动的创世块阶段，一些受信任的节点将作为初始验证人集合运行。开始出块后，任何人都可以作为候选人参与竞选验证人，FON智能链再创世区块中对于验证器最大容忍度为99个验证人，当＞99名验证人后将无法加入成为新的验证人。 权益质押状态决定前 21 个权益质押最多的节点成为下一个验证人集合，这样的选举和淘汰每 3小时进行一次。 ### FON 是FSC权益质押的通证。 为了保持与以太坊共识协议（包括即将到来的升级）的兼容性，FSC 选择独立的权益质押管理。 在 FSC权益质押的模块。 它将接受FON 持有者的FSC权益质押，并计算出权益质押最多节点集。 每次3小时 时，刷新出块人排名，通知 FSC 更新其验证人集合。 在生成新的区块前，现有的FSC验证人定期检查是否有“ValidatorSetUpdate”消息转发到FSC 。 如果有，它们将在一段高度后（即预定义的区块间隔）之后更新验证人集合。 例如，如果 FSC 每 5 秒生成一个区块且检查周期是 240 个区块，那么当前的验证人集合将在 1200 秒（20 分钟）内检查并更新下一周期的验证人集。 ### 安全与最终性 考虑到有超过一半的 ½\*N+1 验证人是诚实可信的，基于 PoA 的网络通常可以安全、正常地工作。 然而在某些情况下，拜占庭验证人仍然可能设法攻击网络， 比如通过“克隆攻击”的方式。 为了保证具FSC安全性，我们鼓励FSC 用户等待到接收的区块被超过⅔\*N+1 不同的验证人所确认，可以容忍少于1/3 \*N 的拜占庭验证人。 对于 21 个验证人，如果区块时间为 5 秒，那么 ⅔\* N + 1 个不同的验证人确认将需要（2/3\*21 + 1）\*5 =75秒的时间。FSC 的任何重要应用程序可能都必须等待⅔\*N + 1，以确保相对安全的最终结果。 ### 共识与验证者的人数 基于以上设计原则，FSC的共识协议是为了实现以下目标： 1\. 出块时间应该比以太坊时间短，例如 5 秒甚至更短。 2\. 只需要等待有限的时间就能最终确认交易，例如大约 1 分钟或更短。 3\. 没有通货膨胀，区块链的收益来自手续费，手续费以FON的形式支付。 4\. 尽可能与以太坊兼容。 5\. 配备了基于权益质押的链上治理机制。 ### 收益 当前验证人集合中的所有 FSC 验证人都将从以FON 支付的手续费中获得收益。由于 FON 不是一个会通胀的通证，因此不会像比特币和以太坊网络那样产生挖矿收益，手续费是验证人的主要收益。 由于FON 也是其他应用的实用型通证，委托人和验证人仍将获得持有FON 的其他好处。 验证人的收益是从每个区块的交易中收取的手续费获得的。验证人获得总验证区块85%的收益，剩余的15%将进入官方财库用于奖励FON生态用户。 每个验证人将以相同的概率轮流生成区块（如果它们保持 100%在线），因此，从长远来看，所有稳定的验证人都可能获得类似规模的收益。 ### 不稳定性 FSC 的可用性依赖于APoS共识中验证人集合中的每个验证人，当轮到其出块时，他们能够及时生成区块。 验证人可能由于一些原因而错过出块时机，特别是由于硬件、软件、配置或网络方面的问题。 这种不稳定运行将损害网络的性能，并给系统带来更多的不确定性。 FSC有一个内部的合约，负责记录每个验证人错过的区块。 一旦该指标超过预定义的阈值，验证人将在当前3小时不再参与出块，从而无法再获得分配的奖励，而是被其他更好的验证人共享。通过这种方式，运行不良的验证人会逐渐退出。 # 跨链机制 FSC使用权益证明共识协议，该协议有机会分叉并需要确认更多块。一个区块只有一个验证者的签名，因此很难依靠一个区块来验证来自FSC的数据。 为了充分利用其他链的验证人法定人数，采用了类似于许多 \[ Bridge ]或Oracle区块链的想法： 来自FSC的跨链通信请求将作为交易提交并执行到FON智能链上。交易的执行会发出\`Events\`，这些事件可以被观察到并打包在某个“ Oracle\*”中到其他链上。这种类型的“Oracle”包没有Block Headers、Hash 和Merkle Proof，而是直接包含动作的跨链信息，例如发送者、接收者和转账金额。 为保证预言机的安全，其他链的验证人将形成另一个法定人数“Oracle Relayers”。其他链的每个验证者都应该运行一个专用进程作为 Oracle Relayer。这些Oracle Relayer 将使用相同的验证器密钥将跨链通信包（如Oracle）提交到其他链并投票。任何由超过⅔ \\\* N+1 Oracle Relayers投票权签名的包与由⅔ \\\* N+1相同法定人数的验证者投票权签署的任何区块一样安全。 通过使用相同的验证者法定人数，它将轻客户端代码保存在其他链上，并将连续的块更新保存到其他链上。此类Oracle还具有Oracle ID和类型，以确保排序和正确的错误处理。 #### 超时和错误处理 存在跨链通信失败的场景。例如，由于合约中的一些编码错误，中继包无法在FSC上执行。超时和错误处理逻辑\*\*用于此类场景。对于可识别的用户和系统错误或任何预期异常，两个网络应该自行修复。例如，当其他链到FSC转账失败时，FSC将发出失败事件，Oracle Relayers将执行其他链退款；当FSC到其他链转账失败时，其他链会发出退款包给Relayer进行中继，以解锁资金。但是，在跨链通信的任何步骤中仍然可能发生意外错误或异常。在这种情况下，Relayers 和Oracle Relayers会发现相应的跨链通道卡在特定的序列中。在超时时间之后，中继器和Oracle中继器可以请求“SkipSequence”事务，卡住的序列将被标记为“不可执行”。将发出相应的警报，社区必须讨论如何处理这种情况，例如通过验证者的赞助商进行回报，或在下次网络升级期间清除资金。 #### 跨链用户体验 理想情况下，用户希望使用两条平行链，就像使用一条链一样。它需要将更多的聚合交易类型添加到跨链通信中才能实现这一点，这将增加极大的复杂性、紧密耦合和维护负担。这里其他链和FSC只实现了初始启动时启用价值流动的基本操作，而将大部分用户体验工作留给客户端UI，例如钱包。例如，一个出色的钱包可能允许用户以安全的方式直接从FSC 将代币出售到其他链的DEX订单簿上。 #### 跨链合约事件 跨链合约事件（CCCE）旨在允许智能合约直接通过合约代码触发跨链交易。这成为可能，基于： ■ 可提供标准系统合约，服务于通用智能合约可调用的操作； ■ 标准事件可以由标准合约发出； ■ Oracle Relayers可以捕获标准事件，触发相应的跨链操作； ■ 可以在其他链上创建专用的、代码管理的地址（账户），并由FSC上的合约访问，这里命名为“其他链上的合约地址”（CAoB）。 实现了几个标准操作： ■ FSC到其他链转账：这与正常的FSC到其他链转账的实现方式相同，仅通过标准合约触发。资金可以转移到其他链上的任何地址，包括转移发起合约的相应CAoB。 ■ 在其他链上转账：这是一种特殊的跨链转账，而真正的转账是从CAoB到任何其他地址（甚至是另一个CAoB）。 ■ 其他链到FSC的转账：这是通过两次跨链通信实现的。第一次由FSC合约触发并传播到其他链，然后在第二次通过时，其他链将开始正常的其他链到FSC的跨链转移，从CAoB到FSC上的合约地址。需要特别注意的是，FSC合约仅在第二遍的任何转账时增加余额，第二遍中的错误处理与正常的其他链到FSC转账相同。 ■ IOC (Immediate-Or-Cancel) Trade Out：将资产转移到其他链的主要目标是进行交易。该事件将指示将CAoB中的一定数量的资产尽可能交易成另一种资产，并将交易的所有结果，即留下的源和交易的目标代币，转回FSC。其他链将通过向交易对发送“立即或取消”（即 IOC 订单）来处理此类中继事件，一旦下一次匹配完成，结果将被中继回 FSC。 ■ Auction Trade Out：该事件将指示其他链发送拍卖订单，将CAoB中的一定数量的资产尽可能多地交易为另一种资产，并在结束时将所有结果转回 FSC拍卖。FSC将推出拍卖功能。 Trade Out有一些细节： ■ 两者都可以有交易的限价（绝对或相对）； ■ 最终结果将被写成跨链包传递回FSC； ■ 转回FSC的资产可能会收取跨链通讯费用； ■ FSC合约维护CAoB上余额和未完成订单的镜像。无论在Trade Out期间发生什么错误，最终状态都会传播回原始合约并清除其内部状态。 有了上述特点，它简单地在FSC上的所有智能合约中添加了具有高流动性的跨链转账和兑换功能。将大大增加智能合约和dApps上的应用场景，实现1链+1链>2链。 # 中继器 ### Relayer中继器 中继者负责在两个区块链之间提交跨链通信包。由于异构并行链结构，创建了两种不同类型的Relayer。 FSC中继器用于其他链到FSC通信的中继器称为“ FSC中继器 ”，或简称为“中继器”。Relayer是一个独立的进程，可以由任何人在任何地方运行，除了Relayer必须在FSC上注册并存入一定数量的可退还代币。FSC仅接受来自已注册中继器的中继请求。 他们中继的包裹将由FSC上的链上轻客户端进行验证。成功的中继需要通过足够的验证，并且需要在FSC上支付Gas费，因此应该有激励奖励来鼓励社区运行Relayer。 ### Oracle中继器 FSC到其他链通信的中继器使用“Oracle”模型，即所谓的“ Oracle Relayers\*”。每个验证器都必须（并且只有验证器集中的验证器）运行Oracle中继器。每个Oracle Relayer都会观察区块链状态的变化。一旦它捕获到跨链通信包，它将提交对请求进行投票。在其他链验证者的 2/3 投票权中的Oracle Relayer投票支持更改后，将执行跨链动作。 Oracle Replayers 应该等待足够的区块来确认FSC上的最终性，然后再将跨链通信包提交并投票到其他链上。 跨链费用将与正常的其他链区块奖励一起分配给其他链验证者。 这种预言机类型的中继依赖于所有要支持的验证器。由于跨链通信包的所有投票都记录在区块链上，因此不难有一个度量系统来评估Oracle Relayers的性能。表现最差的人可能会通过未来引入的另一种 Slashing 逻辑收回他们的奖励。 # 硬分叉、规范与争议解决 ### 硬分叉、规范与争议解决 不同的分布式账本系统通常在底层政治理念和技术选择上有所不同。以太坊项目最初承诺是可 以实现"代码即律法”的”不可停止的应用”。在一个重要的智能合约被黑客攻击之后， 由于缺少这段程序意图做什么的非代码形式的说明书，出现了关于发生的事件到底能不能被描述成黑客攻击的争论。分歧最终导致了社区内部的分裂。 因为FSC合约都是简单的zip文件，所以它很容易就能包含描述合约实际意图的PDF或其它格 式的文档。并没有要求必须使用这个机制，也没有要求这些文档具有法律效力。尽管如此，在金融应用案例中，如果发生了分歧，那么把他们包含的法律意义上的合同比包含的软件实现更为重要。 编写一个不可升级的合约在技术上是可能的。如果这种合约管理一种只存在于账本上的资产， 比如加密货币，那么这可以提供一种近似的”代码即律法"。我们把关于这个理念所蕴含的智慧的讨论留给政治学者和reddit.平台日志在 FSC中没有和区块链的"硬分叉”直接等价的机制，所以放弃问题交易链或欺诈交易链的唯一方法是在带外就抛弃一个完整的交易子图达成一致意见。既然不存在一个全局的可见性，这个一致的达成就不需要包括网络上的所有参与者： 只需要包括那些可能已经接收并处理相关交易的参与者。缺少全局可见性的另一方面后果是没有单个点准确记录了谁见过哪笔交易。确定那些必须就抛弃一个子图 达成一致意见的实体的集合，就意味着需要关联节点的活动日志。 FSC节点用日志记录了充分的信息，可以确保这样的关联可以实现。平台定义了一个任何人可用的流来协助这个过程。还提供了一个能生成”调查请求"并发送到一个种子节点的工具。流通知节点管理员，要求一个决策，并且充足的信息被传递到这个节点，用于尝试说服管理员进行参与（如一个签署的法庭指令）。如果管理员通过节点浏览器接受了这个请求，则交易链中后续的跳转被返回。这个工具以这样的方式半自动地抓取网络，找到所有会被提议的回滚操作所影响的参与者。平台不参与认定什么类型的交易回滚是正当的，在定位必须同意的参与方之外，只对实现回滚操作提供最小的支持。 一旦涉及到的参与者被确认，至少有两种策略可以修改账本。一种是使用简单修正数据库的交易扩展交易链，使其符合预期的现实。为了使这个方法成为可能，编写的智能合约必须在提交的签名达到充分的阈值时能够于正常业务逻辑之外被任意修改。这个策略简单，在状态包含的参与方数量较少且都没有在账本上遗留有害信息的动机时最为有意义。 对于由盗窃或诈骗产生的资产状态，其包含的参与者会反抗所有以上述方法进行修补的尝试， 因为他们可以在账本出错后、恢复到实际状态前的这段时间差里从现实世界获取利益。针对这 种情况，需要使用一种更复杂的方法，即除去不合作参与者之外的所有参与者都同意将相关状态标记为不再被消费或已被花费。这本质上是一种受限形式的数据库回滚。 # 风险评估及决策 区块链作为一项创新技术，不仅仅是在计算机核心技术上有颠覆性的突破，同时也是对个行业领域的革新。因而风险管理体系的重要性不言而喻。基金会秉持建立以风险为导向的可持续经营的区块链社区。基金会将对基金会的运作进行持续性的风险管理。包括风险体系设立、风险评估、风险应对等一系列活动。对于重大风险， 均需基金会战略决策委员会商议讨论并决策。 基金会将根据事件特性，例如事件影响程度、影响范围、影响代币量和发生的概率进行分级，按照优先级进行决策，对于优先级高的事件，尽快组织基金会相关委员会进行决策。 本白皮书内任何内容均不构成法律、财务、商业或税务建议，您应在参与任何与此有关的活动之前咨询自己的法律、财务、商业或其他专业顾问。社区的工作人员、项目研发团队成员、第三方研发组织以及服务商都无需对因使用本白皮书所可能导致的直接或者间接的损害和损失承担责任。本白皮书仅供一般信息参考之用，并不构成招股说明书、要约文件、证券要约、招揽投资或出售任何产品、物品或资产（不论是数字资产还是其他资产）的任何要约。以下信息可能并非详尽无遗，也不意味着具有合约相关的任何要素。 白皮书无法保证信息的准确性或完整性，不保证也不承诺提供信息的准确性和完整性说明。在本白皮书包含从第三方获得的信息的情况下，社区和团队尚未独立验证此类信息的准确性和完整性。此外，您需要了解的是，周围环境和情况可能会随时发生变化，因此本白皮书可能因此而过时，社区没有义务更新或更正与此相关的内容和文件。 本白皮书的任何部分不构成也将不会构成社区、分销商以及任何销售团队（如本协议中所定义的）的任何要约，也不可以将白皮书所陈述的内容作为任何合同和投资决策所依赖的基础。本白皮书中所包含的任何内容都不能作为对未来业绩的陈述、承诺或保证。通过访问和使用该白皮书或其中任何内容时，您将向本社区、其附属机构和您的团队提供如下保证： 在任何购买Token的决定中，您并未依赖本白皮书中的任何声明内容; 您将自愿承担费用并确保遵守适用于您的所有法律、监管要求和限制（视情况而定）; ■ 您承认、理解并同意Token可能没有任何价值，不保证也不代表有任何价值和流通属性，并不可以用来做投机相关的投资; ■ 社区及其附属机构以及团队成员均不对Token的价值、可转让性、流通性以及通过第三方或其他方式提供FSC的任何市场负责或承担责任; ■ 您承认、理解并同意，如果您是满足以下条件的某个地理区域或国家的公民、国民、居民（税务或其他相关的）、居住地或国家绿卡持有人，您将不具备购买任何Token的资格： i.出售Token可能会被定义或解释成为出售证券（无论如何命名）或投资产品； ii.法律禁止接触和参与Token的销售或者Token被法律、政策、条例、条约或行政法规所禁止的国家和地区。 社区和团队不会也不打算向任何实体或个人作出任何陈述、保证和承诺，并在此声明不承担任何责任（包括但不限于本白皮书的内容以及任何社区发布的其他材料内容的准确性、完整性、及时性和可靠性）。在法律允许的最大范围内，社区、相关实体和服务提供商不承担任何因使用了白皮书内容、社区发布的相关材料以及通过其它形式展现的相关内容（包括但不限于任何错误或遗漏的内容）所产生的侵权、合同纠纷或其他形式导致的非直接的、特殊的、偶然的、间接的或其它形式的损失的责任（包括但不限于任何由此产生的违约或疏忽引起的责任、任何收入和利润的损失以及使用方面和数据的损失）。潜在购买者应仔细考虑、评估与销售，社区、分销商和团队相关的所有风险和不确定性（包括财务、法律和不确定性的风险）。 # 免责声明 本白皮书中提供的信息仅供社区讨论，并不具有法律约束力。任何人均无义务就收购FSC订立任何合约和具约束力的法律承诺，除此之外，本白皮书不会接纳任何虚拟货币或其他形式的付款。Token的买卖协议和长期持续持有Token须遵守一套独立条款或一个包含有相关条款和条件的购买协议（视情况而定），这些条款和条件会单独提供给您或可以从网站上获取。如果本条款与条件与本白皮书之间有任何不一致之处，请以本条款与条件为准。 监管机构并没有审查或批准本白皮书中列出的任何信息，而且在任何司法管辖区的法律、法规要求和规则中，都没有规定需要或将要求这样做。本白皮书的发布，分发或传播并不意味着适用的法律、法规的要求或规则已得到履行和遵守。这只是一个概念白皮书，用来描述将要研发的FSC的远景发展目标。本白皮书可能会不时修改或更换。这里并没有更新白皮书和向受众提供超出本白皮书内容范围之外的其它信息的义务。 本白皮书中包含的所有声明、新闻稿和公众可访问的声明以及社区和FSC团队可能做出的口头声明均可构成前瞻性声明（包括相关的意向声明以及对当前市场状况、经营战略和计划、财务状况、具体规定和风险管理决策的信心和预期等方面）。请注意，不要过分依赖这些前瞻性声明，因为这些声明涉及已知和未知的风险、不确定性风险以及其他多方因素，这可能会导致未来实际结果与这些前瞻性声明所描述的内容大不相同，同时，需要说明的是，并没有独立的第三方审查和判断这些陈述和假设的合理性。这些前瞻性陈述仅适用于本白皮书所示的日期，社区和FSC团队明确表示对该日期之后因对这些前瞻性声明进行修订所引起和产生的后果或事件不承担任何责任（无论明示还是默示）。 在此使用的任何公司或平台的名称或商标（除了与社区或其关联公司相关的内容）并不意味着与这些第三方平台和公司有任何关联或得到了其背书。本白皮书中提及的特定公司和平台仅供参考和说明之用。