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-compSupport 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.
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.
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.
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
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.
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.
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!
📣 Announcement Channel (Global)( )
English 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
Tutorial
In this section, we provide a tutorial on the use of different components of the FON Smart Chain.
validator
Tutorial
Tutorial
Key management
This article is a guideline on client key management strategies for FON smart chain decentralized applications
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
If the installation and instantiation of web3 was successful, the following should successfully return a random account:
If you backed up your account private key, you can use it to restore your account.
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.
Ave.ai
Using FON Chain through Ave.ai Wallet
Download the Ave.ai wallet through the Ave.ai official website, and enter the Ave.ai App after the download is complete
After entering the Ave.ai App, click Wallet, connect to the wallet and create it
Bitkeep
Using FON Chain through Bitkeep Wallet
Download the , and enter the Bitkeep App after the download is complete
After entering the Bitkkep App, click to create a wallet, or import a wallet to create a new wallet, click to backup
Create a validator
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:
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:
You need to use the 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.
Validator
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.
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.
Validate contracts at FONSCAN
Step 1: Deploy your contract on the FON smart chain
Step 2: Go to
Click "Verify and Publish"
Step Three: Fill in the correct information for your contract
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.
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.
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.
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.
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
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
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.
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.
All validator candidates will be sorted by the number of delegated tokens they have received, and the top ones will become the real validators.
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.
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.
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: https://github.com/FONSmartChain/fsc-genesis-contract
The initial team destroys 2 million coins
The creation team holds 800,000 coins
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.
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.
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.
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.
■ 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.
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.
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:
The pledged currency is FON because it is the native currency on FSC.
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.
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.
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.
Overview
What is a validator?
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
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.
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.
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
Provide liquidity to RosSwap and pledge to obtain diversified token rewards
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.
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
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.
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.
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.
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.
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.
How to add FON Smart Chain in TokenPocket?
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
Set the wallet name, set the password, and click Confirm. Please be sure to copy the mnemonic in a safe environment for verification
After creating the wallet, click to switch the FSC network, click to select FSC
Click the + icon to select the assets on FSC, and the popular single currency and assets will be loaded automatically
Switch to all FSC transaction lists, click on the market, and select FSC
Back up your mnemonic, please be sure to copy the mnemonic in a safe environment for verification
After creating a wallet, click All Networks to switch to the FSC network
Because Bitkkep supports multiple chains, you can quickly add them by searching for FSC After adding, click the + icon to add assets
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
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
Metamask
1. Step 1 (Open the official website)
Use Google Chrome to enter MetaMask official website https://metamask.io
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
Manually add mainnet network information, as well as RPC and browser related information
Adding the above completes the use of adding the FON Chain network through "MetaMas"
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.
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 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)
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.
prebuilt binaries from the releases page or follow the instructions below
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
Follow the instructions here to set up a full node.
！！！Warning Please do not expose your RPC endpoints to the public network.
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
To resume verification,
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.
URLs vary by instance. With typical installations, access the API by adding /api to the end of the url. For example with the Goerli instance.
URL:
The following modules are supported. Click through to see specific endpoints and parameters.
?module=account
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:
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.
All resources are zero pre-mined, everything starts from scratch, and all participants are on the same starting line to ensure fairness and justice.
Draw blind box double-sign random numbers to eliminate the possibility of anyone grabbing advanced equipment and ensure fairness and openness.
Time Farm Leverage Logic
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.
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.
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.
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:
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:
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.
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.
The game integrates fun, relevance, and circulation, and is complementary and interlocking. Be competitive in the GAMEFI industry!
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.
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.
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.
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.
Blocks are generated by a limited number of validators
Validators take turns generating blocks in a PoA manner, similar to Ethereum’s Clique consensus engine
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:
The block time should be shorter than Ethereum time, such as 5 seconds or even less.
Only need to wait a limited amount of time for the transaction to be finalized, such as about 1 minute or less.
There is no inflation. The revenue of the blockchain comes from handling fees, which are paid in the form of FON.
Be as compatible with Ethereum as possible.
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.
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.
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:
Pay the handling fee for deploying smart contracts on FSC
Pledge the rights and interests of the selected FSC verifiers and obtain corresponding rewards.
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
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.
Validator sets are elected in and out based on stake-based governance
Validators take turns producing blocks in PoA, similar to Ethereum's Clique consensus design
Blocks are produced by a limited set of validators
FSC's consensus protocol achieves the following goals:
The block time is short, 3 seconds on the mainnet.
Confirming the finality of a transaction takes a finite amount of time, about 45 seconds on mainnet.
There is no inflation in the native token FON, and block rewards are collected from transaction fees and paid in FON.
It is 100% compatible with the Ethereum system.
It allows modern proof-of-stake blockchain network governance.
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.
The implementation of the consensus engine is named Parlia, similar to clique. This document will focus more on differences and ignore common details.
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.
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.
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.
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.
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.
Validator Quorum
Paglia
Light client security
System transaction
Forced retreat
Pass interim review
Security and Finality
5. Step five (manually added)
6. Step 6 (Network parameters)
7. Step 7 (Complete the operation)
Kind tips:
Please be sure to keep your mnemonic or private key in a safe place to avoid loss of assets.
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
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
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
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.
List of wallets that support the FON chain
Block
?module=block
Get block reward by block number
getblockreward
Returns the block reward and 'uncle' block rewards when applicable.
Returns the block number created closest to a provided timestamp.
Example:
Parameter
Description
eth_block_number
Mimics Ethereum JSON RPC's eth_blockNumber.
Example:
Parameter
Description
More on .
Logs
?module=logs
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:
*=required field
ETH RPC API
In addition to the custom, the Blockscout ETH RPC API supports 3 methods in the exact format specified for Ethereum nodes, see the 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
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.
In the following examples with the base instance url https://fonscan.io. When sending a request add /api/eth-rpc to the end of the base url.
Returns the latest block number in the chain in hexidecimal format. No params are needed.
Type: POST
Example
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
Type
POST
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
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.
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
Type
POST
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.
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.
if a smart contract is already verified on Sourcify, it will automatically fetch the data from the
otherwise you need to upload source files and JSON metadata file(s).
Example:
Parameter
Description
verify_vyper_contract
Example
curl POST example
Parameter
Description
verifysourcecode
Example
Parameter
Description
checkverifystatus
Example
Parameter
Description
optionalunix 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.
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
optionalstring 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
optionalstring name of the first library used.
library1Address
optionalstring address of the first library used.
library2Name
optionalstring name of the second library used.
library2Address
optionalstring address of the second library used.
library3Name
optionalstring name of the third library used.
library3Address
optionalstring address of the third library used.
library4Name
optionalstring name of the fourth library used.
library4Address
optionalstring address of the fourth library used.
library5Name
optionalstring name of the fifth library used.
library5Address
optionalstring address of the fifth library used.
compilerVersion
string containing the compiler version for the contract.
contractSourceCode
string containing the source code of the contract.
constructorArguments
string constructor argument data provided.
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.
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.
address
string containing the address hash.
address
string containing the address hash.
addressHash
string containing the address hash of the contract.
name
addressHash
string containing the address hash.
files
array with sources and metadata files
addressHash
string containing the address hash of the contract.
name
codeformat
Format of sourceCode (currently only supports solidity-standard-json-input)
contractaddress
guid
stringused for identifying verification attempt
{
"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"
}
Get ABI for a verified contract
Get contract source code for a verified contract
Verify a contract with its source code and contract creation information
On successful submission you will receive a guid as a receipt. Use this with checkverifystatusto view verification status.
{
"message": "OK",
"result": "Pending in queue",
"status": "1"
}
Account
?module=account
eth_get_balance
Mimics Ethereum JSON RPC's eth_getBalance
Example:
Parameter
Description
address
string containing the address hash.
block
optional. 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.
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.
optionalinteger representing the page number used for pagination. 'offset' must also be provided.
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:
Parameter
Description
address
string containing the address hash.
sort
optional sorting preference, asc for ascending and desc for descending. Descending is default.
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:
Parameter
Description
txhash
string representing the transaction hash to check for internal transactions
address
optionalstring containing the address hash.
tokentx
Up to a maximum of 10,000 token transfer events. Also available through the GraphQL token_transfers query.
Example:
Parameter
Description
address
string containing the address hash.
contract address
optional string with the token contract address to identify a contract.
tokenbalance
Example:
Parameter
Description
contract address
string containing the contract address hash.
address
string containing the account address hash to retrieve balance for.
string containing the account address hash to retrieve balance for.
listaccounts
Lists accounts and native balances, sorted ascending by the time they were first seen by the explorer.
Example:
Parameter
Description
page
optionalinteger representing the page number used for pagination. 'offset' must also be provided.
offset
optionalinteger representing number of transactions returned per page. page must also be provided.
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 staleattribute will be set totrue if a new balance is being fetched.
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 balancemulti action. That contains a property called stale that will let you know to recheck that balance in the near future.
Get balance for multiple addresses
Also available through a GraphQL 'addresses' query
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 staleattribute will be set totrue if a new balance is being fetched.
Get pending transactions by address
Get transactions by address
Get internal transactions by transaction or address hash
Get token transfer events by address
Get token account balance for token contract address
Get list of tokens owned by address
Get list of blocks mined by address
Get a list of accounts and their balances
offset
optionalinteger representing number of transactions returned per page. page must also be provided.
start_block
optional integer block number to start transaction search
end_block
optionalinteger block number to stop transaction search.
page
optionalinteger representing the page number used for pagination. offset must also be provided.
offset
optionalinteger 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.
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
optionalinteger block number to stop transaction search. Only available if 'address' is provided.
page
optionalinteger representing the page number used for pagination. offset must also be provided. Only available if 'address' is provided.
offset
optionalinteger representing number of transactions returned per page. page must also be provided. Only available if 'address' is provided.
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
optionalinteger block number to stop transaction search.
page
optionalinteger representing the page number used for pagination. offset must also be provided.
offset
optionalinteger representing number of transactions returned per page. page must also be provided.
