This documentation offers comprehensive details on using and developing applications on the Fantom Opera chain.

Opera

Opera is a blockchain and smart contract platform that provides developers with exceptional scalability and storage capabilities, while delivering a fast and seamless experience for users. Its native token is FTM.

The majority of this documentation aims to help users learn more about Opera and guide developers on building applications on the chain. Bridge assets to Opera to get started.

You can bridge assets to Opera using the protocols below to unlock access to a wealth of apps with instant, cheap transactions.

Wormhole

Use PortalBridge to bridge USDC from Ethereum to Opera. Upon completion, you will receive USDC.e on Opera, the canonical stablecoin for our chain.

Squid Router

To bridge any asset from most EVM chains to Opera, use Squid. Powered by Axelar, Squid automatically swaps and bridges assets for you. It leverages existing DEXs on each chain to swap and bridge native tokens.

Axelar handles all cross-chain gas conversion from the source-chain token to the destination-chain token, so users don’t need to maintain wallets on different chains, hold tokens for gas fees, or make multiple transactions to complete a transfer.

For example, you can bridge ETH on Arbitrum to FTM on Opera in one step.

Running a validator node on the Opera chain presents a unique opportunity to actively contribute to the security and decentralization of the network. By participating as a validator, you help validate transactions and create new blocks, ensuring the integrity and efficiency of the blockchain.

This involvement not only supports the broader ecosystem but also provides potential financial incentives through rewards distributed to validators. Additionally, being a validator offers a deeper understanding and engagement with blockchain technology, positioning individuals and organizations at the forefront of a rapidly evolving industry. It is a chance to be part of a community driving innovation and fostering a robust, decentralized future.

Follow the tutorials in the menu to get started!

Rabby Wallet includes a feature that automatically switches the wallet to the appropriate chain based on the site you visit. As such, it should switch to Opera automatically when you visit an app.

Below are the most frequently asked questions specifically regarding the migration process from Fantom Opera to Sonic.

is the official wallet for the Opera chain, required to participate in staking or governance.

You can connect to fWallet using various third-party wallets, including Rabby, MetaMask, Coinbase Wallet, and others.

With fWallet, you can:

• Send FTM and other tokens

• Swap tokens, powered by OpenOcean

comes preloaded with the Opera chain. As such, it should switch to Opera automatically when you visit an app.

Developers should build on the Opera chain due to its impressive performance, scalability, and low transaction costs, all enabled by its .

Opera provides fast transaction finality, typically within one second, which ensures a seamless user experience for applications. Additionally, the chain's compatibility with the Ethereum Virtual Machine (EVM) allows developers to easily port their existing Ethereum apps to Opera with minimal modifications

Furthermore, Opera's commitment to decentralization and high throughput positions it as a forward-thinking platform capable of supporting a wide range of applications, from DeFi to NFTs and beyond, making it a versatile and attractive choice for developers aiming to build next-generation blockchain solutions.

Follow the tutorials in the menu to get started!

Staking on Opera involves locking up a certain amount of FTM (Opera's native token) to support the network's operations, such as block production and validation. In return, users receive rewards in the form of additional FTM. This process helps secure the network and maintain its integrity.

Validators are required to stake at least 50,000 FTM to validate transactions and produce blocks to earn rewards. However, users can delegate any amount from 1 FTM to existing validators to earn rewards without needing the technical knowledge to operate a validator.

Opera uses a fluid staking model. Users can either stake without a lock-up period for the minimum annual percentage rate (APR) or select a lock-up period between 14 and 365 days for an increased APR. This model combines long-term sustainability for the network with flexibility for stakes.

Rewards

In the fluid staking model, your effective APR:

• Increases proportionally with your lock-up period

• Decreases proportionally with the average lock-up period of all stakers

• Decreases proportionally with the total amount of FTM staked by all stakers

To get an estimate for potential rewards, please use our rewards calculator.

Staking on Opera

There are two ways to participate in staking on Opera:

• Run a validator node

• Delegate to an existing validator node

Smart contract unit tests are written in JavaScript. In this tutorial, we provide two examples of unit testing using Hardhat and Truffle.

Unit Testing in Hardhat

https://github.com/Fantom-foundation/unittestexample-hardhat

Unit Testing in Truffle

https://github.com/Fantom-foundation/unittestexample-truffle

Each example repository contains the following:

• contracts Folder: Contains smart contract files.

• test Folder: The unit test files are under the test folder.

• README.md File: Contains instructions for compiling, testing, deploying, and verifying the smart contracts.

In the above examples, unit tests are included in one single JavaScript file. However, you can have as many tests and files as you need for your project. In the examples, there are three types of tests:

1. Checking if a value is what is expected

2. Checking if an event is fired with the correct arguments

3. Checking if a revert has occurred

Staking is a vital part of securing the Opera chain through proof-of-stake. Validator nodes must stake FTM, incentivizing them to act honestly in block production as they risk losing their stake otherwise.

However, FTM holders can also participate by staking their FTM and delegating it to an existing validator node to earn rewards. Opera offers several staking benefits, including no minimum stake, no mandatory lock-up period, and liquid staking services!

How to Stake FTM

1. Head to fWallet.

2. Click on Staking

3. Choose the amount of FTM you would like to stake and then click on Choose a validator

4. Click on Create new delegation

5. Choose a validator from the list

6. Click Stake and continue

7. Choose between the 1.8% base APR with no lock-up period or lock your stake for up to 365 days for an increased APR

Once you have staked, you’ll begin to earn rewards actively. 15% of the rewards you earn will be distributed as a fee to the node to which you’ve delegated your stake.

To increase your FTM stake amount at any time, you can repeat the process above to create a new delegation. As such, you can create several delegations with multiple lock-up periods.

Rewards and Compounding

The Rewards section of the Staking page shows the amount of FTM you have earned from staking.

You can compound these rewards into your delegations to increase your stake and earn more rewards, or you can claim all rewards to receive the FTM directly in your wallet.

Unbonding Period

Note that there's a seven-day unbonding period when you unstake your FTM. After initiating the unstaking process, you must wait for seven days. Once this period has passed, return to the Staking page, navigate to the Withdraw tab, and withdraw your FTM to your wallet.

Additionally, while it is possible to unstake your FTM before your chosen lock-up period ends, you’ll receive only half of the base rate of 1.8% APR rewards; however, since you receive rewards actively, the penalty will be deducted from your staked FTM as you unstake.

For example, you stake and lock 100,000 FTM for one year, giving you a 6% APR, which equals 6,000 FTM in total rewards. Approximately at day 300, you’ll have received almost 5,000 FTM, at which point you decide to unstake before the one-year period ends.

Your updated APR is 0.9%, half the base rate. With your 100,000 FTM, your rewards would equal 900 FTM. However, since you’ve already received 5000 FTM, you’ll receive only 95,900 FTM when you unstake to account for the extra 4100 FTM in rewards you forfeit by unstaking early.

As such, you will never receive less FTM than you staked originally.

Governance on a decentralized platform empowers token holders to actively shape and influence its future, ensuring it evolves in the right direction. On Opera, governance is an on-chain process that lets FTM (Opera's native token) stakers submit and vote on proposals that determine changes to the platform’s mechanics and tokenomics.

Voting

To vote on a proposal, go to the governance section in your fWallet, open an active proposal, and cast your vote on the choice with which you agree most. Note that you’ll need to stake FTM tokens to vote. Each token equals one vote.

When you delegate your stake to a validator, your voting power is still equal to the number of FTM tokens you’ve staked. However, if you choose not to vote on a proposal, your voting power is given to your validator who adds your votes to their own. This helps to increase overall participation and prevent low voting turnouts. Once you do vote, they lose your voting power.

Proposals

Governance proposals outline potential actions that aim to improve Opera. If you’ve staked FTM, you can submit one by paying a 100 FTM fee through the governance section of your fWallet.

Proposals aren’t restricted to a simple yes or no option — voters can express their level of agreement across a range of custom options, which allows for more nuanced decision-making.

Proposals have a set date by which a minimum number of voters must have participated, and they must have agreed above a certain percentage. For most proposals, at least 55% of FTM stakers must cast their vote, and the average agreement among them must also be 55% or higher for the proposal to pass, both of which need to be achieved by a certain date.

If a proposal passes, the Fantom Foundation will implement the proposed changes or upgrades.

GraphQL API

The API server delivers a high-performance GraphQL API for Opera, offering access to both low-level and aggregated blockchain data for remote clients. This allows client developers to focus on their application's business logic, without having to manage the complexity of data and entity relationships within Opera.

The API server is published on the fantom-api-graphql GitHub repository.

Technology

We utilize several technologies to ensure the API functions effectively. If you intend to run your own instance, please review our setup and ensure you have at least a basic understanding of these technologies before proceeding.

First, you will need access to the Opera full-node Lachesis RPC interface. While you can use a properly configured remote interface, this may significantly impact performance and potentially compromise the security of your deployment. Be mindful of the security risks associated with exposing the RPC to outside access, especially if you enable "personal" commands on your node while storing your account keys in the Lachesis key store. We recommend using a local IPC channel for communication between the Lachesis node and the API server. The IPC interface is available by default. Refer to the Lachesis launch instructions and go-opera repository for detailed deployment and configuration guidance.

Some aggregated and relationship data are stored off-chain in a MongoDB database, particularly data that is not easily accessible via the basic node RPC interface. This includes references between an account and its transaction history or the chronological position of transactions. The API server initializes the database, populates it with historical data, and keeps it synchronized with the full node through internal subscriptions. While you don't need to manage the database separately, you must provide a well-configured and reliable database connection address to the API server.

Finally, the server is developed using Go, a fast, secure, and excellent programming language. You will need to install and configure a Go development environment to build your copy of the API server. Please follow the official Go installation instructions.

Finally, the server itself is developed using Go, excellent, fast and secure programming language. You will need to install and configure Go development environment to be able to build your copy of the API server. Please follow the official installation instructions.

With the previous proxy pattern, we can only have one logic or implementation smart contract. However, there are cases when we want to have one proxy with more than one logic smart contract. In this case, we need the diamond proxy pattern, which is also known as the multi-facet proxy pattern.

After verifying your proxy smart contract and its logic (implementation) smart contract, you can execute the functions via FTMScan. However, like the other EVM explorers, such as Etherscan, FTMScan can’t support a verified diamond proxy and its logic smart contracts, also known as facets. Fortunately, now we have a diamond inspector called Louper which also supports the Opera mainnet and testnet.

Here are two samples of a diamond proxy and its facets which can be inspected using Louper:

• https://github.com/Fantom-foundation/diamondproxy-hardhat

• https://github.com/Fantom-foundation/diamondproxy-truffle

Fantom has migrated to the new Sonic chain and its S token. Users holding FTM can upgrade to S.

Migration Overview

Here is an overview of the migration timeline and associated events:

Our Opera chain provides developers with exceptional scalability and storage capabilities while delivering a fast and seamless user experience.

Opera achieves beyond 2,000 transactions per second with near one-second finality for immediate, irreversible transactions and utilizes a cutting-edge storage system for efficient data management.

Learn more about the Opera technology stack:

• Consensus

• Database Storage

• Proof of Stake

• Transaction Fees

Every transaction on Opera requires a fee, paid in FTM (Opera's native token), to prevent spam attacks and compensate validators for processing transactions.

Rewards Distribution

The current distribution of transaction fees is:

• 5% burned

• 10% to the Ecosystem Vault

• 15% to Gas Monetization

• 70% to validators

The Opera chain is secured using a proof-of-stake (PoS) mechanism.

In PoS on Opera, validators must lock their FTM (Opera's native token); if they act maliciously in the network, they lose their tokens. Validators are incentivized to act in the network's best interest as their own funds are at stake. Since validators do not need to perform computations, this approach is a much more energy-efficient alternative to proof-of-work for achieving resistance to Sybil attacks!

A Sybil attack is an attack where a malicious actor runs a large number of validators to allow them an unsafe amount of influence over the network. PoS makes it costly to set up these validators and allows the network to punish validators for malicious behavior, increasing the costs of attacks.

Opera requires validator nodes to lock up at least 50,000 FTM to validate transactions and produce blocks.

Rewards Estimation

Estimated rewards calculation uses the current status of the blockchain to approximate the amount of FTM rewarded for participating in staking. The network uses a proof-of-stake consensus variant to ensure the security of the data inside the blockchain structure.

To calculate the rewards, we use the baseRewardPerSecond value of the latest sealed epoch, but the total staked amount of tokens is calculated elsewhere. The epoch provides the total value of self-staked tokens and the amount of total delegated tokens within that epoch. However, the self-staked total does not account for temporarily offline nodes and includes delegated stakes in the process of being undelegated. Consequently, this value is not accurate for our calculations.

To get the current total staked value, we iterate all the staking records and collect the total staked amount from individual staking.

Delegation Limits

The delegation limit is determined by multiplying the staker's current self-staked amount by a fixed rate specified in the SFC contract. Currently, the maximum allowed delegations are set at 15 times the self-staked FTM.

To calculate the remaining delegation limit, we subtract the current delegated amount from the total limit. This value is provided by the API, so you don't need to perform the calculation manually. Note that tokens in the process of undelegation are not included in the delegated amount and therefore do not count towards the delegation limit.

Fixed-cap assets are fungible tokens for which the supply is determined at the time of asset creation. No additional quantities can be generated afterward.

Create the Asset

1. Write the token smart contract:

   2. Functions

      1. Fixed-cap assets

         1. constructor(cap)

         2. cap()

         3. _beforeTokenTransfer(from, to, amount)

      2. General

         1. name()

         2. symbol()

         3. decimals()

         4. totalSupply()

         5. balanceOf(account)

         6. transfer(recipient, amount)

         7. allowance(owner, spender)

         8. approve(spender, amount)

         9. transferFrom(sender, recipient, amount)

         10. increaseAllowance(spender, addedValue)

         11. decreaseAllowance(spender, subtractedValue)

         12. _transfer(sender, recipient, amount)

         13. _mint(account, amount)

         14. _burn(account, amount)

         15. _approve(owner, spender, amount)

         16. _setupDecimals(decimals_)

2. Compile your code into bytecode

3. Deploy your fixed-cap asset by sending your code in a transaction to the Opera network

4. Navigate to to check that your token has been created

Verifying your smart contract creates transparency, thus increasing trust. Follow these steps to verify your smart contract on Opera:

1. Go to .

2. Input your contract address.

3. Choose compiler type (single file is recommended).

4. Choose the compiler version (according to your contract).

5. Choose the open-source license.

6. Click Continue.

   1. If you select a single file as compiler type, then you can use a library like sol-merger to flatten your contract. It creates a single file that contains all the imports.

   2. Make sure there is only one line of // SPDX-License-Identifier. If there are multiple lines of this, remove them except the first one.

7. Choose yes for optimization (if you deployed your contract using Hardhat).

8. Paste the source code.

9. If the contract has a constructor, then you need to create the ABI code for the values passed to the constructor. Use . Copy the result and paste it to the Argument (Constructor) section.

10. Tick the box to indicate that you are not a robot.

11. Verify and publish.

Verify cia Command Line and Script

You can verify your contracts via a Hardhat or Truffle command line. You need to get a scan API key from first. Register if you do not have an account and then create a scan API Key. Hover over your username and then choose API Keys. You then can create an API Key.

You then need to store the API Key in a .env file which is read by your configuration file, such as: API_KEY={your API Key}. Your Hardhat configuration hardhat.config.js may look like this:

Your Truffle configuration truffle-config.js may look like:

Below are two examples of command lines to verify your contract, one in Hardhat and the other in Truffle configuration.

In the above examples, it is assumed that you supplied some values to the constructor when you deployed the contract.

• Using the Hardhat command line: When verifying using the Hardhat command line, you need to specify the values in a JavaScript file. In the example above, it is assumed that the file is under the scripts folder. Please refer to the .

• Using the Truffle command line: You do not need to specify any value that you passed to the contract's constructor. Truffle records these when you deploy the contract.

If you use Hardhat, you can also use the verify:verify command in a script to verify your contract. You can include this script in your deployment script. .

Opera utilizes a major part of the Ethereum Virtual Machine (EVM) in the backend. Smart contracts are written in Solidity and they can function on Opera as they do on Ethereum.

To deploy a smart contract, you send an Opera transaction containing your bytecode without specifying any recipients. You will need FTM tokens to pay the gas fees when deploying smart contracts. To request your testnet FTMs on the testnet, you can use the .

After the contract is deployed, it will be available to all users of the Opera network. Smart contracts have an Opera address like other accounts.

Requirements

• Bytecode (compiled code) of your smart contract

• FTM for gas costs

• Deployment script/plugin

• Access to an Opera node, either by running your own node or API access to a node

Example of Smart Contract Deployment

If you are deploying a smart contract on Opera for the first time, you may take a look at the .

The repository contains the materials to deploy a smart contract using Hardhat and Truffle tools. Instructions to work with the mainnet and testnet are included.

Deployment Using Remix

If you want to deploy a smart contract using Remix to the Opera testnet, you just need to connect MetaMask to the Opera Testnet and choose Injected Provider - MetaMask in the Environment option.

You can see that the network ID is set to 4002, which is the Opera testnet's chain ID. When you deploy the contract, it will be deployed to the Fantom testnet.

Additional Resources

Tools

• : Development environment for editing, compiling, debugging, and deploying your smart contracts using the EVM.

• : Development environment, testing framework, and asset pipeline for blockchains using the EVM.

• : IDE that’s used to write, compile, debug, and deploy Solidity code in your browser.

• : Solidity is an object-oriented, high-level programming language for implementing smart contracts.

• : OpenZeppelin Contracts helps you minimize risk by using battle-tested libraries of smart contracts for Ethereum and other blockchains.

• : Complete Web3 development framework that provides everything you need to connect your applications and games to decentralized networks.

Variable-cap assets are fungible tokens for which additional quantities can be minted after creation.

Create the Asset

1. Write the token smart contract:

   2. Functions

      1. name()

      2. symbol()

      3. decimals()

      4. totalSupply()

      5. balanceOf(account)

      6. transfer(recipient, amount)

      7. allowance(owner, spender)

      8. approve(spender, amount)

      9. transferFrom(sender, recipient, amount)

      10. increaseAllowance(spender, addedValue)

      11. decreaseAllowance(spender, subtractedValue)

      12. _transfer(sender, recipient, amount)

      13. _mint(account, amount)

      14. _burn(account, amount)

      15. _approve(owner, spender, amount)

      16. _setupDecimals(decimals_)

2. Compile your code into bytecode

3. Deploy your Variable-cap Asset by sending your code in a transaction to the Fantom network

4. Navigate to to check that your token has been created

5. You can use the _mint function to create additional units of the token

Follow the tutorial below to add the Opera mainnet or testnet to .

How to Add Opera to MetaMask

Desktop

1. Open your MetaMask extension

2. Click the network icon in the top-left corner

3. Click Add Network

4. Click Add a Network Manually

5. Fill in the details below:

   1. Network Name: Opera

   2. RPC URL: https://rpcapi.fantom.network

   3. Chain ID: 250

   4. Currency Symbol: FTM

   5. Block Explorer URL: https://ftmscan.com/

6. Click Save

7. Switch your MetaMask wallet to Opera

Mobile

1. Open your MetaMask app

2. Click the network drop-down list at the top

3. Click Add Network

4. Click Custom Networks

5. Fill in the details below:

   1. Network Name: Opera

   2. RPC URL: https://rpcapi.fantom.network

   3. Chain ID: 250

   4. Currency Symbol: FTM

   5. Block Explorer URL: https://ftmscan.com/

6. Click Add and Confirm

7. Switch your MetaMask wallet to Opera

Opera Testnet

To add the Opera testnet to MetaMask, follow the steps above but replace the network details with:

1. Network Name: Opera Testnet

2. RPC URL: https://rpc.testnet.fantom.network/

3. Chain ID: 0xfa2

4. Currency Symbol: FTM

5. Block Explorer URL:

You can access the for some free testnet FTM.

Signing a Transaction

Here’s an to update the blockchain state by creating a transaction. demonstrates updating a state variable in a deployed contract:

1. We call the function setGreeting and store the transaction in a variable tx

2. We then pass the tx along with contract details

3. The function signTransaction creates a block of data containing all the necessary information like gas price, contract information, network information, etc., and calls the web3 method to sign the transaction.

Gas Price

We have added to fetch the gas price:

1. web3.eth.getGasPrice() gets the latest gas price

2. web3.eth.getFeeHistory() gets the gas price using custom parameters, such as:

   1. No. of blocks (the number of previous blocks it searches)

   2. String/BN value to request the newest block in the requested range

   3. Percentile options (1-99th percentile)

   4. CallBack

getFeeHistory() will calculate an average of the blocks (mentioned in the first parameter) and figure out the best gas prices based on the percentile for slow/average/fast options. This API also returns the baseFeePerGas (introduced after EIP-1559) which is added to the gas prices outputted by the above call.

Rest of the Web3 API calls and examples on Opera:

Transfer

We have added two ways to sign a transaction with a of transferring FTM between accounts.

transfer

The takes a simple approach and uses the predefined web3 method to determine the gas price required to send FTM between two accounts.

transferWithParams

transfers with additional parameters in its transaction block.

The code snippet mentioned above employs the variables maxFeePerGas and maxPriorityFeePerGas. Following the London fork, each block now includes a baseFeePerGas. This base fee represents the minimum cost required for sending a transaction on the network. Unlike miners, the network itself determines the base fee. The base fee varies from block to block depending on the previous block's capacity.

When submitting a transaction, you must also provide a "tip" in the maxPriorityFeePerGas field. To ensure that the miner has an incentive to process your transaction, the minimum tip amount you should offer is 1 wei. The likelihood of your transaction being included in a block increases as you offer a higher tip. To initiate a transaction on the network, users have the option to specify the maximum amount they are willing to pay for their transaction to be executed. This parameter is called maxFeePerGas. However, for a transaction to be successfully executed, the max fee specified must be greater than or equal to the sum of the base fee and the maxPriorityFeePerGas.

Liquid staking on Opera allows users to unlock liquidity from staked assets, opening new opportunities within DeFi. Traditionally, if you , you lock your tokens to support the network's operation and security in exchange for rewards. However, doing this makes your FTM illiquid, meaning they cannot be used for other DeFi opportunities until they’re unstaked.

On Opera, two protocols aim to fix this limitation: and . Learn about them below.

What is Liquid Staking?

Liquid staking addresses the limitations of traditional staking by delegating your tokens to a validator and then minting synthetic tokens that represent the staked assets on a 1:1 basis. These tokens can then be freely traded and used in DeFi protocols for lending, borrowing, or earning additional yield while the original assets remain staked and continue earning staking rewards.

For example, suppose you stake 100 FTM through one of the liquid staking providers below. In that case, you receive the equivalent value in their FTM liquid staking tokens, which you can use in any DeFi application that supports them.

Liquid staking on Opera enhances the utility of its native token and enriches its DeFi ecosystem, making it more attractive to users seeking to maximize the productivity of their assets. This mechanism fosters greater capital efficiency within the network, allowing users to participate in securing Opera while also engaging in other DeFi activities without having to choose one over the other.

Beethoven X

Beethoven X is a DeFi platform on Opera that offers liquid staking through its sFTMx token. Follow these steps to liquid stake using Beethoven X:

1. Head to

2. Select how many FTM you wish to stake

3. Click Stake and confirm in your wallet

You have now staked your FTM through Beethoven X and received an equivalent value in sFTMx tokens! These tokens are reward-bearing, meaning their quantity is stable, but they gain in value such that their redemption ratio grows daily to reflect Opera staking rewards. The tokens can now also be used across various DeFi applications while they continue to earn staking rewards from the Opera chain.

To unstake your FTM, head to the Unstake tab. However, please note that any FTM tokens you unstake will only be available for withdrawal after 7 days, identical to the waiting period required for unstaking native FTM. As an alternative to unstaking, you can swap from sFTMx to FTM using Beethoven X’s DEX on the Swap page.

15% of the staking rewards that you earn are given to the validator on which your underlying FTM is staked, and then Beethoven X takes a 10% protocol fee from the remaining rewards that you receive. about liquid staking on Beethoven X.

Ankr Protocol

Ankr offers liquid staking on Opera through its ankrFTM token. Follow these steps to liquid stake using Ankr:

1. Visit

2. Select how many FTM you wish to stake

3. Click Get ankrFTM and confirm in your wallet

You have now staked your FTM through Ankr and received an equivalent value in ankrFTM tokens! These tokens are reward-bearing, meaning their quantity is stable, but they gain in value such that their redemption ratio grows daily to reflect Opera staking rewards. The tokens can now also be used across various DeFi applications while they continue to earn staking rewards from the Opera chain.

To unstake your FTM, head to the , scroll to the Liquid staking section, and click the minus symbol next to the ankrFTM token. Note the unstaking period given above the Unstake button. As an alternative to unstaking, you can swap from ankrFTM to FTM on various DEXs.

15% of the staking rewards that you earn are given to the validator on which your underlying FTM is staked, and then Ankr takes a 15% technical service fee from the remaining rewards that you receive. about liquid staking on Ankr.

Node Requirements

Minimum hardware requirements:

• AWS EC2 m5.xlarge with 4 vCPUs (3.1 GHz), SSD (gp2) storage

• CPU > 3.0 GHz

• SSD (or NVMe SSD) (N.B. AWS gp2 has up to 16000 IOPS)

• Network Bandwidth: 1 Gbps (N.B. m5.xlarge has up to 10 Gbps)

• Storage: Depending on the types of your nodes.

Equivalent or better specs are recommended.

Data Pruning

To save machine's storage, you may use pruning (for further ).

• Manual pruning:

  Stop the node, then issue the following command: ./opera snapshot prune-state

• Automatic pruning:

  You can run a node with the --gcmode flag, and it will prune old data on the fly.

  • Full gcmode: This can be enabled by --gcmode full, which prunes old VM tries. It will need more RAM. Often, --cache 15000 (or more RAM) is required to ensure normal operation in this mode.

  • Light gcmode: The light gcmode version (adopted from geth) is less aggressive. It is used by --gcmode light flag. It requires less RAM usage than full gcmode.

Cache Size

One can specify the cache size by --cache <size in MB>. The default value of cache size is 3200 MB. Nodes tend to sync faster with a larger cache size.

Transaction Ordering

Transactions in blocks aren't necessarily sorted by gas price. Even though transactions in each event and in the txpool are sorted by gas price, events are sorted by their topological ordering in the DAG. A new block includes transactions from multiple confirmed events in that topological order, which is used by our .

Penalty for Unspent Gas

It is recommended that you make sure to submit transactions with a reasonable gas limit amount.

This is because transactions with excessive gas limits will have less chance to be included, due to a gas limit for each block, and the originating power of validators. There is penalty of 10% for unspent gas. This penalty is introduced as a disincentive against excessive transaction gas limits.

The disincentive is required because Opera is a leaderless decentralized aBFT chain and blocks are not known in advance to a validator (unlike Ethereum miners) until blocks are created from confirmed events. There is no single proposer who can originate transactions for a whole block and so validators don't know the used gas in advance.

This penalty will be increased shortly (up to 50%) to prevent transactions with excessive transaction gas limits.

Requirements

Please note that an official binary distribution is not available at the moment. To build your own GraphQL API, you need to have the following:

• Working database installation.

• Go version 1.13 or later .

• up and running.

You do have another option. For initial testing and development, you can use our own testing playground. The API server is deployed at https://xapi2.fantom.network/api for regular GraphQL queries and at https://xapi2.fantom.network/graphql for WebSocket subscriptions.

Feel free to connect and try your queries. Fine-tune your application before committing to deploying your own instance.

Building Process

Building your API server is a fairly straightforward process. First, clone the repository to your local machine. Do not clone the project into $GOPATH, due to the . Instead, use any other location.

Once you have the copy on your machine, build the executable:

To run your copy of the API server, simply run:

Configuration

The API server already contains some most common configuration options as default values, and you don't have to change them most of the time. The default values are:

• Network binding address is localhost.

• Default listening port is 16761.

• Default Lachesis IPC interface is ~/.lachesis/data/lachesis.ipc.

• MongoDB connection address is mongodb://localhost:27017.

• Default logging level is INFO.

If you want to change one of the default values, you need to create a configuration file. The API server can read configuration options from several configuration formats, namely JSON, TOML, YAML, HCL, envfile, and Java properties config files.

Please choose the one you are most familiar with. The name of the configuration file is expected to be "apiserver" with an extension that corresponds with the file format of your choosing.

Example YAML file looks like this:

You can keep the config file in the same location as the API server executable, or you can save it in the home folder under the .fantomapi sub-folder. On MacOS, the expected path is Library/FantomApi.

is a free contract-centered blockchain explorer created by . First released in 2018, Contract Library continuously decompiles and analyzes all deployed contracts for human inspection and offers a platform for exposing vulnerabilities. Contracts added to the Opera chain appear in the library almost immediately.

Contract Library offers users the ability to:

Contract Library’s debugger is orders of magnitude more scalable than alternatives on other networks, enabling debugging complex transactions within a reasonable amount of time. This is achieved by implementing an efficient model of the EVM to offload computation from the Web3 client.

In the proxy pattern, we have two smart contracts: proxy contract and implementation contract.

The proxy contract acts as a proxy, delegating all calls to the contract it is the proxy for. In this context, it will also be referred to as the Storage Layer. The implementation contract is the contract that you want to upgrade or patch. This is the contract that the Proxy contract will be acting as a proxy for. In this context, it is the Logic Layer.

The Proxy contract stores the address of the implementation contract or logic layer as a state variable. Unlike normal contracts, the user doesn't actually send calls directly to the logic layer, which is your original contract. Instead, all calls go through the proxy and this proxy delegates the calls to this logic layer — the implementation contract at the address that the proxy has stored — returning any data it received from the logic layer to the caller or reverting for errors.

The key thing to note here is that the proxy calls the logic contract through the delegatecall function. Therefore, it is the proxy contract that actually stores state variables, i.e. it is the storage layer. It is like you only borrow the logic from the implementation contract (logic layer) and execute it in the proxy's context affecting the proxy's state variables in storage.

Openzeppelin provides a library to create an upgradeable proxy pattern called TransparentUpgradeableProxy.

Creating the Proxy and Proxy Admin Implicitly

Below are two samples of the creation of a TransparentUpgradeableProxy, one in Hardhat using @openzeppelin/hardhat-upgrades and the other one in Truffle using @openzeppelin/truffle-upgrades

When you deploy, the package behind the scenes creates a ProxyAdmin and a TransparentUpgradeableProxy as well.

In the Hardhat configuration, you just need to verify the TransparentUpgradeableProxy. The Hardhat utility will also verify the ProxyAdmin and the logic smart contract, Box. Unfortunately, in the Truffle configuration, we can’t do this. We can only verify the logic smart contract.

Creating the Proxy and Proxy Admin Explicitly

We can create the proxy and proxy admin explicitly by inheriting TransparentUpgradeableProxy in @openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol and ProxyAdmin in @openzeppelin/contracts/proxy/transparent/ProxyAdmin.sol.

Below are two samples of creating the proxy and proxy admin explicitly.

Unfortunately, MyProxy can’t be verified using the command line in Hardhat or Truffle, but we can flatten it and then verify it on FTMScan directly.

Opera uses database storage to store its world state, which includes account information, virtual machine bytecode, smart contract storage, etc. This database has a feature called live pruning, which removes historical data automatically, reducing storage needs for validators as the blockchain grows.

Previously, pruning required validator nodes to go offline, risking financial and operational issues for them. Now, validators can use live pruning without going offline, ensuring continuous operation and saving on disk space and costs by discarding historical data in real-time.

Live pruning works by splitting the database into two types: LiveDB and ArchiveDB. The LiveDB contains the world state of the current block only, whereas the ArchiveDB contains the world states of all historical blocks. Validators use only LiveDB, while archive nodes have both LiveDB and ArchiveDB to handle historical data requests through the RPC interface.

Opera's database storage uses efficient tree-like or hierarchical structures, which simplifies data retrieval. Importantly, it still provides cryptographic signatures for a world state and archive capabilities using an incremental version of a prefix algorithm. Additionally, it utilizes a native disk format instead of storing the world state indirectly through key-value stores like LevelDB or PebbleDB.

is an open-source smart contract wallet operating on the Opera chain, designed for multi-signature management of crypto assets and interactions with other smart contracts, making it ideal for team fund management.

You can designate owners of the safe and specify the minimum number of approvals required for a transaction to be executed. This differs from a single-key wallet, also known as an externally owned account (EOA), where one person holds the private key and approves transactions independently.

Fantom Safe supports FTM and tokens on the Opera chain, allowing you to transfer them to the safe as usual. You can view the fiat values of your assets on your dashboard and conveniently send funds from it.

Getting Started

As is based on Gnosis Safe, you can use most tutorials based on them. For selecting the Opera mainnet or test net, use the menu in the top-right corner.

Transaction Service API

We offer an sent via Fantom Safe smart contracts.

Troubleshooting

Due to the caching mechanism, transaction nonces can become unsynchronized. If a transaction cannot be created from your Safe, verify that the current nonce for your Safe transaction matches the nonce displayed in the Safe UI.

To resolve this, open the settings menu of your Fantom Safe to view the current nonce. Copy this nonce into your Safe transaction, and the issue should be resolved.

Opera Mainnet

RPC

• https://rpcapi.fantom.network/

• https://rpc.ankr.com/fantom/

• https://fantom-mainnet.public.blastapi.io/

• https://rpc.ftm.tools

• https://fantom-rpc.gateway.pokt.network

• https://1rpc.io/ftm

• https://fantom.publicnode.com

• https://fantom.blockpi.network/v1/rpc/public

• https://fantom.drpc.org/

• https://rpc.fantom.gateway.fm

• https://endpoints.omniatech.io/v1/fantom/mainnet/public

• https://fantom.api.onfinality.io/public

• https://fantom.rpc.thirdweb.com/

Chain ID: 250 Symbol: FTM Explorer: https://ftmscan.com List provided by CompareNodes.

GraphQL

• https://xapi.fantom.network/

WS

• wss://wsapi.fantom.network/

• wss://fantom-mainnet.public.blastapi.io/

Transaction Tracing

• https://rpcapi-tracing.fantom.network

Opera Testnet

RPC

• https://rpc.ankr.com/fantom_testnet/

• https://xapi.testnet.fantom.network/lachesis/

• https://rpc.testnet.fantom.network/

• https://fantom-testnet.public.blastapi.io/

• https://fantom-testnet.publicnode.com

• https://fantom-testnet.drpc.org/

• https://endpoints.omniatech.io/v1/fantom/testnet/public

• https://fantom-testnet.rpc.thirdweb.com/

Chain ID: 4002 Symbol: FTM Explorer: https://testnet.ftmscan.com/

WS

• wss://fantom-testnet.public.blastapi.io/

Transaction Tracing

• https://rpcapi-tracing.testnet.fantom.network

Validator Parameters

• Minimum hardware requirements: AWS EC2 m5.large with 8GB RAM, 2 vCPUs, and at least 300GB of Amazon EBS General Purpose SSD (gp2) storage (or equivalent).

• We would recommend going with Ubuntu Server 22.04 LTS (64-bit).

Network Settings

Open up port 22 for SSH, as well as port 7946 for both TCP and UDP traffic. A custom port can be used with "--port <port>" flag when running your Opera node.

Install Required Tools

You are still logged in as the new user via SSH. Now we are going to install Go and Opera.

First, install the required build tools:

# Install build-essential
(validator)$ sudo apt-get install -y build-essential
# Install go
(validator)$ wget https://go.dev/dl/go1.19.3.linux-amd64.tar.gz
(validator)$ sudo tar -xvf go1.19.3.linux-amd64.tar.gz
(validator)$ sudo mv go /usr/local
# Export go paths
(validator)$ vi ~/.bash_aliases
# Append the following lines
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH
#
source ~/.bash_aliases

Run a Read Node

You can run your read node using go-opera 1.1.3-rc.5 (full sync or snapsync mode).

# Install Opera
(validator)$ git clone https://github.com/Fantom-foundation/go-opera.git
(validator)$ cd go-opera/
(validator)$ git checkout release/1.1.3-rc.5
(validator)$ make

Validate your Opera installation:

$./build/opera help

VERSION:
1.1.3-rc.5

db.preset

When using version 1.1.3, you need to add the db.preset argument (introduced since 1.1.2) to the starting Opera command. You can see options for this parameters with opera help command. For standard conditions, please use this option:

• db.preset=ldb-1

You can use different db presets, either --db.preset ldb-1 OR --db.preset legacy-db or --db.preset pbl-1. Note that ldb-1 is recommended.

Download a genesis file from this list of genesis files.

# Start opera node
(validator)$ cd build/
(validator)$ wget https://download.fantom.network/testnet-6226-no-mpt.g
(validator)$ nohup ./opera --genesis testnet-6226-no-mpt.g --nousb \
            --db.preset ldb-1 &

You can start a node with a syncmode flag. There are two possible options:

• "--syncmode snap", and

• "--syncmode full" (by default).

For archive node and validator node, you should use full syncmode.

For the latest update, please check our GitHub.

Validator Node

Rerun a Node if Stopped

If your node is stopped (for any reason), please examine the server log to identify if there were any issues. After fixing the issues (if any), you can run the node in read mode to sync to the latest block. After it is synced up, you can stop the node and run in validator mode.

Make sure your node is synced in read mode first before it is run in validator mode.

Migration to New Server

If you'd like to migrate your node to a new server, please follow these steps:

1. Set up a read node on a new server and allow it to run to sync to the latest block.

2. Stop the old node for at least 40 minutes before running the validator mode on the new server

3. After the old node is stopped for 40 minutes, then you can run in validator mode on the new server. You should not let the old node run again as it will result in a double-sign and slashing of your validator node.

How to Stop Node

Find the running process of opera using ps and then kill the process by id.

After your node is stopped, if you want to rerun it, don't run directly in validator mode. Instead, please make sure your node is synced in read mode first before it's run in validator mode.

Offline Node

If your validator node is down for more than 5 days, then it will become offline (i.e. pruned from the network).

For offline nodes, you can undelegate and wait for 7 days to withdraw (bonding time). After that, you can transfer funds to a new wallet and make a new validator if you wish. If undelegating a locked stake or locked delegation before the locked period has expired, it will incur a penalty.

How to Permanently Shut Down Node

To shut down a node permanently, you can simply stop running the node in validator mode for 5 days or more.

How to Unstake

If your node stake is locked, you will first need to call unlockStake() to unlock it. Note that a penalty will apply for early unlocking before the lock-up period has expired. Then you can call undelegate(), to unstake your stake. Then there is a waiting period of 7 days (so-called bonding time) after undelegation. This is required before you can call withdraw() to take out your stake.

Syncing Error

If your node is in a dirty state (it may happen occasionally), please run: opera --db.preset legacy-ldb db heal --experimental alternatively, you may do a fresh resync as follows:

• Stop the node

• Remove the current (broken) datadir (the default datadir is located at ~/.opera)

• Download and build the latest version go-opera 1.1.3-rc5

• Run your node again in read mode

Slow Syncing

Check your machine specs if it meets the minimum requirements.

• IOPS greater than 5000 (higher is better)

• Connection speed > 1 Gbps (some run with 10 or 20 if they can)

• Cores: More than 4 cores (the number of cores is not important unless you will use it for serving API calls)

• CPU: > 3 GHz.

You can also check the following flags if you're using them to run your node. You can adjust to values suitable to your usage.

• Maxpeers Flag: default is 50, you can adjust it depending on your machine

• Cache Flag: --cache 15792 (A larger value can give better performance)

• Gcmode: Gcmode is not enabled by default. If enabled, gcmode (light or full) will take some extra CPU and time

You can also increase the value of ulimit on your machine.

Increase Open Files Limit

You can check your current limit value on Linux with the command ulimit -n. The default value of 1024 may be not enough in some cases.

You can adjust the value to the recommended 500.000 open files limit by either:

• ulimit -n 500000

• Change it in the /etc/security/limits.conf configuration file, limit type nofile.

The Gas Monetization program offers apps a 15% share of the gas fees they generate and aims to provide high-quality apps with a sustainable income, retain talented creators, and support network infrastructure.

With Gas Monetization, we seek to foster a thriving ecosystem for builders, similar to the ad-revenue model on traditional web platforms.

Participate in Gas Monetization

Approval to the Gas Monetization program is at our discretion. Apply to participate in Gas Monetization.

Upon approval to participate in the program, apps will begin to earn 15% of the gas fees they generate. The FTM earned through Gas Monetization can be used at the apps' discretion.

Quarterly Bonus

Every quarter, the top 12 apps on Opera that generated the most gas will receive a bonus. These 12 projects are divided equally into four tiers that determine the amount of FTM they receive:

• Tier 1 (top three projects): 40% of FTM

• Tier 2 (next three projects): 30% of FTM

• Tier 3 (next three projects): 20% of FTM

• Tier 4 (final three projects): 10% of FTM

The quarterly bonus comes from the 15% deducted from transaction fees of apps not participating in Gas Monetization. While 15% of all transaction fees on Opera are allocated to the Gas Monetization program, the fees from non-participating apps are pooled and distributed as the quarterly bonus.

Double-Spend Dilemma

In Gas Monetization, double counting is prevented by accurately tracking gas consumption within the EVM. The system traces all internal calls in a transaction and splits the reward based on the gas each sub-operation consumes.

This ensures that the sum of rewards across different projects never exceeds the total gas fee. An example is given below.

• A trade consumes 100,000 units of gas with a total GasM fee of 0.017 FTM.

• Inside this transaction, there are operations related to two projects: Project A and Project B.

• Project A, the DEX aggregator, is responsible for consuming 37,000 units of gas, while Project B, the liquidity pool on the DEX that the aggregator interacts with, uses 63,000 units of gas.

• The total reward is split based on the gas consumption:

  • Project A receives 37% of the fee (0.00629 FTM).

  • Project B receives 63% of the fee (0.01071 FTM).

• The total reward still adds up to 100% of the 0.017 FTM GasM fee, ensuring no over-distribution.

Terms & Conditions

We reserve the right to suspend rewards to participating apps for any reason deemed necessary at its sole discretion, including fraudulent user activity or the overall well-being of the Opera ecosystem.

Follow the tutorial below to add FTM to your Ledger device and interact with apps on Opera.

How to Add FTM to Ledger

1. Open Ledger Live

2. Click on My Ledger

3. Under App Catalog, find Ethereum and click Install

   1. Since Ledger lacks a native Opera application, we use the Ethereum application as it supports all EVM-compatible chains, including Opera.

4. Follow the instructions to install the Ethereum app

5. Click Add Account

6. Select FTM in the drop-down list and add the account

How to Send FTM to Ledger

1. Open Ledger Live

2. Click Accounts

3. Click on your Fantom account

4. Click Receive

5. Choose your Fantom account in the drop-down list

6. Click Continue

7. Verify the address on your Ledger device and then copy

8. Send FTM to this address from CEXs or other wallets

How to Use Apps with Ledger

To use apps on Opera with your Ledger device, you must connect it to a Web3 wallet first, such as Rabby or MetaMask.

Rabby

1. Open your Rabby Wallet extension

2. Click on your wallet address at the top

3. Click Add New Address and then Connect Hardware Wallets

4. Click Ledger

5. Connect your Ledger and click Next

6. Click Allow and choose your Ledger device in the list

7. Choose your address on the list that contains FTM and click Done

You can now interact with apps on Opera using Rabby. Whenever you need to sign a transaction or message, Ledger will prompt you to approve it on your physical hardware wallet.

MetaMask

1. Open your MetaMask extension

2. Click the drop-down list at the top

3. Click Add Account or Hardware Wallet

4. Click Add Hardware Wallet

5. Click Ledger

6. Click Continue and choose your Ledger device in the list

7. Choose your address on the list that contains FTM and click Unlock

You can now interact with apps on Opera using MetaMask. Whenever you need to sign a transaction or message, Ledger will prompt you to approve it on your physical hardware wallet.

Opera's canonical stablecoin is USDC.e, supported by Circle and Wormhole.

USDC.e on Wormhole is bridged from native USDC, located in a smart contract on Ethereum, and holds the potential to be upgraded to native USDC in the future by Circle. It's the official, endorsed stablecoin of the Opera ecosystem.

Bridge USDC to Opera

To bridge USDC from Ethereum to Opera, use PortalBridge. You will receive USDC.e on Opera upon completion, which is the canonical stablecoin for our chain.

Native vs. Bridged USDC

According to Circle, the differences between native USDC and bridged USDC are:

Unlike native USDC, bridged USDC isn’t minted by Circle itself. On Opera, USDC.e is minted by Wormhole, bridged from native USDC located in a smart contract on Ethereum. At any point, Circle can then obtain ownership of the USDC.e token contract on Opera and upgrade it to native USDC.

Pathway to Native USDC

Circle has outlined these steps for upgrading bridged USDC to native USDC:

1. Wormhole has deployed USDC.e on the network

2. USDC.e is used to bootstrap initial liquidity in the ecosystem

3. USDC.e reaches a significant supply, amount of holders, and number of app integrations

4. Circle and the Fantom Foundation/Wormhole jointly elect to securely transfer ownership of the USDC.e token contract to Circle

5. Upon obtaining ownership, Circle upgrades USDC.e to native USDC and seamlessly retains existing supply, holders, and app integrations

The Fantom Foundation will provide liquidity for the USDC.e stablecoin on Wormhole, making it easy for the token to spread across the network and for users to bridge assets to Opera. As USDC.e begins to proliferate and gain a vast amount of holders and app integrations, Circle may consider stepping in to upgrade its token contract to native USDC.

In this scenario, the upgrade would be seamless and wouldn’t require developers to update contract addresses or users to swap to the new token. The automatic changeover ensures that native USDC on Opera can leverage the built-up USDC.e liquidity so there isn't any interruption on the network.

Create Contract

To create a new smart contract using the thirdweb CLI, follow these steps:

1. In your CLI run the following command:

   Copy

   
   npx thirdweb create contract
   

2. Input your preferences for the command line prompts:

   1. Give your project a name

   2. Choose your preferred framework: Hardhat or Foundry

   3. Name your smart contract

   4. Choose the type of base contract: Empty, ERC20, ERC721, or ERC1155

   5. Add any desired extensions

3. Once created, navigate to your project’s directory and open in your preferred code editor.

4. If you open the contracts folder, you will find your smart contract; this is your smart contract written in Solidity. The following is code for an ERC721Base contract without specified extensions. It implements all of the logic inside the ERC721Base.sol contract, which implements the ERC721A standard.

   Copy

   
   // SPDX-License-Identifier: MIT
   pragma solidity ^0.8.0;
   
   import "@thirdweb-dev/contracts/base/ERC721Base.sol";
   
   contract Contract is ERC721Base {
       constructor(
           string memory _name,
           string memory _symbol,
           address _royaltyRecipient,
           uint128 _royaltyBps
       ) ERC721Base(_name, _symbol, _royaltyRecipient, _royaltyBps) {}
   }
   

   This contract inherits the functionality of ERC721Base through the following steps:

   • Importing the ERC721Base contract

   • Inheriting the contract by declaring that our contract is an ERC721Base contract

   • Implementing any required methods, such as the constructor.

5. After modifying your contract with your desired custom logic, you may deploy it to Opera using Deploy.

Alternatively, you can deploy a prebuilt contract for NFTs, tokens, or marketplace directly from the thirdweb Explore page:

1. Go to the thirdweb Explore page: https://thirdweb.com/explore

2. Choose the type of contract you want to deploy from the available options: NFTs, tokens, marketplace, and more.

3. Follow the on-screen prompts to configure and deploy your contract.

Deploy Contract

Deploy allows you to deploy a smart contract to any EVM-compatible network without configuring RPC URLs, exposing your private keys, writing scripts, and other additional setups, such as verifying your contract.

1. To deploy your smart contract using deploy, navigate to the root directory of your project and execute the following command:

   Copy

   
   npx thirdweb deploy
   

   Executing this command will trigger the following actions:

   • Compiling all the contracts in the current directory.

   • Providing the option to select which contract(s) you wish to deploy.

   • Uploading your contract source code (ABI) to IPFS.

2. When it is completed, it will open a dashboard interface to finish filling out the parameters.

   • _name: contract name

   • _symbol: symbol or "ticker"

   • _royaltyRecipient: wallet address to receive royalties from secondary sales

   • _royaltyBps: basis points (bps) that will be given to the royalty recipient for each secondary sale, e.g. 500 = 5%

3. Select Opera (Fantom) as the network

4. Manage additional settings on your contract’s dashboard as needed such as uploading NFTs, configuring permissions, and more.

If you have any further questions or encounter any issues during the process, please reach out to thirdweb support at support.thirdweb.com.

This section guides you through deploying a Hello World smart contract using Chainstack and Foundry on the Opera testnet.

If you have any questions, reach out in the Chainstack Discord.

Deploy an Opera Testnet Node

You need a node to deploy a smart contract to the chain. To get your node:

1. Sign up with Chainstack.

2. Deploy a testnet node.

3. Get the deployed node’s HTTPS endpoint.

Install Foundry

Foundry is a development toolkit to work with smart contracts.

1. Install Rust.

2. Install Foundry.

Initialize With Foundry

In your project directory, run foundry init. This will create a boilerplate project.

Fund Your Account

You need to pay gas on the network to deploy the contract. Get testnet FTM through the faucet.

Create the Hello World Contract

In the initialized Foundry project in src/, create HelloWorld.sol:

// SPDX-License-Identifier: None

// Specifies the version of Solidity, using semantic versioning.
// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
pragma solidity >=0.8.9;

// Defines a contract named `HelloWorld`.
// A contract is a collection of functions and data (its state). Once deployed, a contract resides at a specific address on the Fantom blockchain. Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
contract HelloWorld {

   //Emitted when update function is called
   //Smart contract events are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen.
   event UpdatedMessages(string oldStr, string newStr);

   // Declares a state variable `message` of type `string`.
   // State variables are variables whose values are permanently stored in contract storage. The keyword `public` makes variables accessible from outside a contract and creates a function that other contracts or clients can call to access the value.
   string public message;

   // Similar to many class-based object-oriented languages, a constructor is a special function that is only executed upon contract creation.
   // Constructors are used to initialize the contract's data. Learn more:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
   constructor(string memory initMessage) {

      // Accepts a string argument `initMessage` and sets the value into the contract's `message` storage variable).
      message = initMessage;
   }

   // A public function that accepts a string argument and updates the `message` storage variable.
   function update(string memory newMessage) public {
      string memory oldMsg = message;
      message = newMessage;
      emit UpdatedMessages(oldMsg, newMessage);
   }
}

Deploy the Contract

At this point, you are ready to deploy your contract:

• You have your own node on the Opera testnet through which you will deploy the contract.

• You have Foundry that you will use to deploy the contract.

• You have a funded account that will deploy the contract.

To deploy the contract, run:

forge create HelloWorld --constructor-args "Hello" --contracts CONTRACT_PATH --private-key PRIVATE_KEY --rpc-url HTTPS_ENDPOINT

• CONTRACT_PATH — path to your HelloWorld.sol file.

• PRIVATE_KEY — the private key from your account.

• HTTPS_ENDPOINT — your node's endpoint.

Example:

forge create HelloWorld --constructor-args "Hello" --contracts /root/foundry/src/HelloWorld.sol --private-key d8936f6eae35c73a14ea7c1aabb8d068e16889a7f516c8abc482ba4e1489f4cd --rpc-url https://nd-123-456-789.p2pify.com/3c6e0b8a9c15224a8228b9a98ca1531d

Congratulations! You have deployed your Hello World smart contract on Opera!

See the Chainstack documentation for more tutorials and tools.

This guide addresses as many questions you may have about Opera as possible. Please refer to this FAQ section before asking questions on our social channels. If your question is still unanswered, please reach out to us.

General Questions

What is a consensus algorithm?

A consensus algorithm is a mechanism for reaching agreement among nodes in distributed networks. It removes the need for a central authority and allows the whole network to trustlessly agree on data and the ordering of events.

Nodes in the network maintain an exact copy of the ledger, allowing applications built on top of the consensus protocol to function correctly.

What is finality?

Finality means that any party cannot change or reverse a transaction. ABFT consensus algorithms, such as the one Opera uses, have a very low time to finality because they achieve absolute finality. Absolute finality means a transaction is considered final once included in a block. In the case of Opera, the chain can achieve finality in 1–2 seconds.

Conversely, Nakamoto consensus protocols rely on probabilistic finality. In this case, the probability that a transaction will not be reverted increases with time. The more blocks created on top of a block, thereby confirming it as correct, the more difficult and costlier it would be to revert a transaction in that block. At some point, it becomes theoretically impossible to alter older blocks, increasing the probabilistic finality to nearly 100%.

Bitcoin has a finality of 30–60 minutes; when using Bitcoin, you must wait a few block confirmations before considering the transaction final and irreversible. Ethereum has a finality of a few minutes.

FTM Token

Is FTM an ERC-20 token?

Opera has an ERC-20 token, but it cannot be used directly on the Opera chain.

Here is a breakdown of the different FTM tokens in circulation at the moment:

1. Opera FTM: Used on the Opera chain 2. ERC-20: Exists on the Ethereum network

Note that Opera addresses share the same structure as Ethereum addresses (0x…), but they are not Ethereum addresses.

Can I send ERC-20 FTM tokens to my Opera wallet?

No. You need to transfer them over to Opera using a bridge.

What’s the purpose of the FTM token?

The FTM token has several use cases within the Opera ecosystem. It is essential for a well-functioning, healthy network.

1. Securing the network Opera uses a proof-of-stake system that requires validators to hold FTM. Anyone with at least 50,000 FTM can run their validator node to earn rewards and secure the network. Every FTM holder can delegate their tokens to a validator (while keeping full custody of their funds) to receive staking rewards. Validators then charge a small fee for their services. By locking in their FTM, validators help the network to be decentralized and secure.

2. Paying for network fees To compensate validators for their services and prevent transaction spam, every action performed within the Opera network costs a small fee, paid in FTM.

3. Voting in on-chain governance Decisions regarding the Opera ecosystem are made using transparent on-chain voting. Votes are weighted according to the amount of FTM held by an entity. 1 FTM equals 1 vote.

4. Additional use cases FTM is used to earn APR/APY on many DeFi platforms.

How can I stake FTM?

Check out our guide.

Can I stake FTM on exchanges like Binance?

You cannot stake FTM on exchanges at the moment.

How to run a validator on Opera?

To run a validator node on the Opera chain, the following is required:

1. A minimum stake of 50,000 FTM

2. Google GCP N2 instance or AWS i3en.xlarge with 4 vCPUs (3.1 GHz) and at least 1TB of local NVMe SSD storage (or equivalent).

Check out our guide.

Where can I store FTM?

You can store FTM on various hardware and hot wallets. Check out the Wallets section to learn more.

Opera Chain

What is Opera?

Opera is our mainnet, a fully decentralized blockchain network with smart contract support. It is compatible with the Ethereum Virtual Machine and powered by our ABFT consensus algorithm. Thus, smart contracts developed on Ethereum can run on Opera, increasing scalability and security.

Is Opera compatible with Ethereum smart contracts?

Yes. Fantom is fully compatible with the Ethereum Virtual Machine (EVM) and supports Web3JS API and RPC.

All smart contracts written in Solidity or Vyper, compiled and deployed on Ethereum, are fully compatible with Opera.

What programming languages does Opera support?

Opera supports all the smart contract languages Ethereum supports for the EVM, including Solidity and Vyper.

When did Opera mainnet go live?

The Opera chain went live on December 27, 2019.

How is Opera governed?

The Fantom Foundation is currently in charge of the network's governance, advised by the community and validator nodes.

Find out more details on how governance works on Opera.

Basics

The core idea of the GraphQL API is to describe available entities and attributes with a schema and let the client decide which parts, elements, and services it needs to perform its operation. Our schema is extensively commented and you should be able to grab the right data just by comparing your needs with the schema. Please let us know if you still miss anything important.

Conventions

The API follows these conventions and recommendations:

• GraphQL types are capital camelCases.

• Attributes are regular camelCases.

• Function calls are named and managed the same way as attributes.

• Complex input and output values are encapsulated in a type instead of an expanded list.

• Each type, attribute, and function has a comment describing its purpose.

Scalar Values

The API uses several different scalar values besides the default GraphQL set. Most of them encode big values or byte arrays of hashes and addresses. If your client application is built using JavaScript, or TypeScript, you can benefit from using the excellent Ethereum Web3.js library, which can help you deal with the decoding and validating process of most data types used here.

The following scalar values are used by the API:

• Hash is a 32-byte binary string, represented by 0x prefixed hexadecimal number.

• Address is a 20-byte Opera address, represented by 0x prefixed hexadecimal number.

• BigInt is a large integer value. Input is accepted as either a JSON number or a hexadecimal number alternatively prefixed with 0x. Output is 0x prefixed hexadecimal.

• Long is a 64-bit unsigned integer value represented by 0x prefixed hexadecimal number.

• Bytes is an arbitrary length binary string, represented by a 0x-prefixed hexadecimal string. An empty byte string is represented by '0x'.

• Cursor is an unspecified string value representing position in a sequential list of edges. Please see the following section for details about Cursor usage.

Pagination

The API employs cursor-based pagination instead of the commonly used <offset, count> or <from, to> architectures, which rely on numeric offsets from the top of the collection. In our scenario, the top of the collection is constantly changing, making it nearly impossible to track your position with a shifting anchor.

Our approach uses a cursor system, where each member of the collection has a unique identifier called a cursor. To obtain a slice of the collection, you specify the cursor value of a member and the number of neighboring members you need. If you don't specify a cursor, it defaults to either the top or bottom of the collection, determined by the count of neighbors you request.

For example, this query provides 15 consecutive blocks after the one with the cursor "0x134b7":

query BlocksList {
    blocks (cursor: "0x134b7", count: 15) {
        totalCount
        pageInfo {
            first
            last
            hasNext
            hasPrevious
        }
        edges {
            cursor
            block {
                hash
                number
                timestamp
                transactionCount
            }
        }
    }
}

If you just want the 10 most recent transactions, you skip the cursor and send the following query:

query TransactionsList {
    transactions (count: 10) {
        totalCount
        pageInfo {
            first
            last
            hasNext
            hasPrevious
        }
        edges {
            cursor
            transaction {
                hash
                from
                to
                value
                block {
                    timestamp
                }
            }
        }
    }
}

Please note that each response will contain several important bits of info that will help you navigate through the collection.

First is the pageInfo structure, defined by PageInfo type. It contains the first and last cursor of your current slice so you can use these values and ask for next X edges or previous -X edges.

Also each edge of the list contains not only the desired data element, but also a cursor, which can be used to create a link, if desired, to the same position in the collection regardless of the absolute distance of the element from the top or bottom.

This page outlines token migration options for apps from Fantom Opera to the Sonic chain.

It provides comprehensive guidance for both token holders and project owners regarding their migration options.

Introduction

Covalent is a hosted blockchain data solution providing access to historical and current on-chain data for 100+ supported blockchains, including Opera.

Covalent maintains a full archival copy of every supported blockchain, meaning every balance, transaction, log event, and NFT asset data is available from the genesis block. This data is available via:

1. Unified API — Incorporate blockchain data into your dApp with a familiar REST API

2. Increment — Create and embed custom charts with no-code analytics

Use Covalent if you need:

• Structured and enhanced on-chain data well beyond what you get from RPC providers

• Broad and deep multi-chain data at scale

• Enterprise-grade performance

Unified API

The Covalent API is RESTful and offers the following for Opera:

Getting Started

• API Key — Sign up for free

• Quickstart — Summary of key resources to get you building immediately on the blockchain

• API Reference — Try all the endpoints directly from your browser

• Guides — Learn how to build dApps, fetch data, and expand your Web3 knowledge

Increment

Increment is a novel no-code charting and reporting tool powered by Covalent, revolutionizing how the Web3 space approaches analytics. Many analytics tools let you write SQL to create charts, but Increment is the only one to encode business logic - Reach, Retention, and Revenue - into an SQL compiler that can write valid SQL for you.

Use Cases

Increment can be used for:

• Analyzing Blockchain Networks

• Analyzing DEXs

• Analyzing NFT Marketplaces

For example, click on the following table to get the latest number of active wallets, transactions, and tokens by day, week, month, or year for Fantom:

Getting Started

• Increment — Log in via the Covalent Platform

• Docs — Learn how to use Increment to build dynamic, custom charts

• Data Models Demo — Build analytics in 3 clicks

• Explore Models. Seek Alpha. — Browse all data models

• Use Models. Become Alpha. — Use a data mode

Consensus in a decentralized system is not just a process but a cornerstone of the system. Its mechanism guarantees a consistent and secure blockchain among all participants and ensures the system's integrity and reliability. Consensus ensures that transactions are consistently and securely validated and added to the blockchain. It's a critical element for effectively thwarting attempts by malicious actors to manipulate the network or its data. Opera uses Asynchronous Byzantine Fault Tolerance in combination with directed acyclic graphs to achieve consensus.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance (PBFT) is a consensus mechanism designed to enable decentralized systems to function correctly in the presence of malicious or faulty nodes. It is named after the Byzantine generals’ problem, which is an idea that illustrates the difficulties of achieving consensus in a decentralized system when some of the participants may be acting in bad faith.

In a PBFT system, nodes in a network communicate with each other to reach a consensus on the system's state, even when malicious actors are involved. To achieve this, they send messages back and forth that contain information about the system's state and the actions they propose.

Each node verifies the message it receives, and if it determines the message is valid, it sends a message to all the other nodes to indicate its agreement. In the context of cryptocurrencies, the message with which all nodes must agree is the blockchain, a ledger that stores a history of transactions.

Before the invention of cryptocurrencies, the major flaw with PBFT systems was their susceptibility to Sybil attacks. If an attacker controlled a sufficient number of nodes, they could control the entire system; there needed to be a deterrent to launch many nodes. Bitcoin first solved this problem with proof-of-work, forcing nodes to invest considerable energy to partake in the consensus.

Since then, many new solutions have been developed, such as proof-of-stake, which forces nodes to deposit tokens with monetary value, which Opera uses.

Hence, Practical Byzantine Fault Tolerance (PBFT) is a mechanism to achieve consensus. It forms a functioning decentralized system when coupled with proof-of-work or proof-of-stake to deter participants from messing with the network. However, Opera has decided to innovate on this mechanism by using Asynchronous Byzantine Fault Tolerance.

Asynchronous Byzantine Fault Tolerance

With Asynchronous Byzantine Fault Tolerance (ABFT), nodes can reach consensus independently and are not required to exchange final blocks sequentially to confirm transactions. At the same time, they exchange blocks, which is required to achieve consensus, and this is done asynchronously. Each node verifies transactions independently and is not required to incorporate blocks created by other miners or validators in sequential order.

This is opposed to PBFT systems, such as Bitcoin, in which the majority of nodes must agree to a block before it becomes final, which they must then sequentially order into their blockchain record. This slows down the network during high traffic; more on this in the consensus mechanism section further below.

Now that we have a basic understanding of Byzantine fault tolerance, let’s delve into the second part of Opera’s consensus mechanism, directed acyclic graphs.

Directed Acyclic Graphs

A graph is a non-linear data structure used to represent objects, called vertices, and the connections between them, called edges. A directed graph dictates that all its edges, the connections between objects, only flow in a certain direction. An acyclic graph does not contain any cycles, which makes it impossible to follow a sequence of edges and return to the starting point. As such, a directed acyclic graph (DAG) only flows in a certain direction and never repeats or cycles.

The diagram below is an example of a directed acyclic graph. Each oval is a vertex, and the lines connecting them are edges. The vertices only connect in one direction, downwards, and never repeat.

In our consensus algorithm, an event containing transactions is represented by a vertex in a DAG, and edges represent the relationships between the events. The edges may represent the dependencies between events indicating the order in which they were added to the DAG.

Events can be created and added to the DAG concurrently. The blocks do not need to be added in a specific order, which enables the system to achieve faster transaction times. It is not limited by the requirement to incorporate blocks sequentially, as is the case with many of the biggest blockchains currently available.

Opera's Consensus Mechanism

Opera uses a proof-of-stake, DAG-based, ABFT consensus mechanism. In this mechanism, each validator has its own local block DAG and batches incoming transactions into event blocks, which they add to their DAG as vertices — each event block is a vertex in the validator’s DAG that is full of transactions.

Before creating a new event block, a validator must first validate all transactions in its current event block and part of the ones it has received from other nodes; these are the event blocks it has received during the asynchronous exchange of event blocks explained in the section above. The new event block then is communicated with other nodes through the same asynchronous event communication.

During this communication, nodes share their own event blocks, and the ones they received from other nodes, with other validators that incorporate them in their own local DAGs. Consequently, this spreads all information through the network. The process is asynchronous as the event blocks shared between validators are not required to be sequential.

Unlike most blockchains, this DAG-based approach does not force validators to work on the current block that is being produced, which places restrictions on transaction speed and finality. Validators are free to create their own event blocks that contain transactions and share these with other validators on the network asynchronously, creating a non-linear record of transactions. This increases transaction speed and efficiency.

As an event block is sent and propagated across validators, it becomes a root event block once the majority of validators have received and agreed upon it. This root event block will eventually be ordered and included in the main chain, which is a blockchain that contains the final consensus among all event blocks that have become root event blocks.

Every validator stores and updates a copy of the main chain, which provides quick access to previous transaction history to process new event blocks more efficiently. As such, Opera's consensus mechanism combines a DAG-based approach that allows validators to confirm transactions asynchronously, which greatly increases speed, with a final blockchain that orders and stores all final transactions immutably and indefinitely.

Currently, the process of submitting a transaction and having it added to the Opera main chain through the consensus mechanism takes approximately 1-2 seconds. This involves the following steps:

1. A user submits a transaction

2. A validator node batches the transaction into a new event block

3. The event block becomes a root event block once the majority of nodes have received it

4. The root event block is ordered and finalized into the main chain as a block

When a user explores Opera through a block explorer, they view the final blocks on the Opera main chain. Event block generation and exchange in validators' DAGs is an internal process only and is not visible to end users.

For a more technical understanding of Opera's consensus mechanism, read Lachesis: Scalable Asynchronous BFT on DAG Streams.

Introduction

is a collaborative project to deliver traditional API services to smart contract platforms in a decentralized and trust-minimized way. It is governed by a decentralized autonomous organization (DAO), namely the .

For more info about API3, check out its .

First-Party Oracles

An is a first-party oracle that pushes off-chain API data to your on-chain contract. Airnode lets API providers easily run their own oracle nodes. That way, they can provide data to any on-chain app that's interested in their services, all without an intermediary.

Using dAPIs — API3 Datafeeds

are continuously updated streams of off-chain data, such as the latest cryptocurrency, stock and commodity prices. They can power various decentralized applications such as DeFi lending, synthetic assets, stablecoins, derivatives, NFTs, and more.

The data feeds are continuously updated by using signed data. App owners can read the on-chain value of any dAPI in real-time. Due to being composed of first-party data feeds, dAPIs offer security, transparency, cost-efficiency, and scalability in a turn-key package.

Apart from relying on deviation threshold and heartbeat configuration updates, unlike traditional data feeds, enables apps using dAPIs to auction off the right to update the data feeds to searcher bots. Searcher bots can bid for price updates through the OEV Network to update the data feeds. All the OEV proceeds go back to the app.

The enables users to connect to a dAPI and access the associated data feed services. to learn more about how dAPIs work.

Subscribing to dAPIs

The lets users access dAPIs on both the and .

Exploring, Selecting, and Configuring Your dAPI

The provides a list of all the dAPIs available across multiple chains, including testnets. You can filter the list by mainnet or testnet chains. After selecting the chain, you can now search for a specific dAPI by name. Once selected, you will land on the details page (eg ETH/USD on the Opera Testnet) where you can find more information about the dAPI.

The currently supported configurations for dAPIs are:

Activating Your dAPI

If a dAPI is already activated, make sure to check the expiration date and update the parameters. You can update the parameters and extend the subscription by purchasing a new configuration.

After selecting the dAPI and the configuration, you will be presented with an option to purchase the dAPI and activate it. Make sure to check the time and amount of the subscription. If everything looks good, click on Purchase.

You can then connect your wallet and confirm the transaction. Once it's confirmed, you will be able to see the updated configuration for the dAPI.

Getting the Proxy Address

Once you are done configuring and activating the dAPI, you can now integrate it. To do so, click on the Integrate button on the dAPI details page.

You can now see the deployed proxy contract address. You can now use this to read from the configured dAPI.

Reading From a dAPI

Here's an example of a basic contract that reads from a dAPI:

• setProxyAddress() is used to set the address of the dAPI Proxy Contract.

• readDataFeed() is a view function that returns the latest price of the set dAPI.

You can read more about dAPIs .

Additional Resources

Here are some additional developer resources:

In this guide, we will walk you through the steps of using , , and , all of which are popular developer tools, to create and deploy a simple smart contract on Opera. Note that this tutorial will use the Opera testnet, but the steps remain the same for the mainnet.

Requirements

Before we begin, make sure you have the following:

• MetaMask or another Web3 wallet

• Remix: An online IDE used to write, compile, deploy, and debug Solidity code

• GetBlock API key: GetBlock provides access to RPC endpoints for various blockchain networks, including Opera

  • To obtain an API key from GetBlock, register on and find the API key in your account

• GetBlock RPC endpoint

  • To obtain an RPC endpoint from GetBlock, register on and add a new endpoint by choosing Opera (Fantom) as the protocol and testnet as the network

Create Contract

A) Configure MetaMask to connect to Opera using GetBlock RPC endpoints

1. Open MetaMask and set up a custom network with the following details:

   1. Network Name: Opera Testnet

   2. New RPC URL: The GetBlock RPC endpoint you created

   3. Chain ID: Obtain the Chain ID for Opera from GetBlock documentation or API (e.g. 4002)

   4. Symbol: FTM

   5. Block Explorer URL:

B) Get test tokens on the Fantom testnet

1. Visit the

2. Input your MetaMask wallet address

3. Complete the CAPTCHA and request the testnet FTM

C) Connect Remix with the Opera network using GetBlock RPC endpoints

1. Go to the

2. On the Remix home page, choose the Solidity environment

3. With the Opera network selected in MetaMask, go to Remix and click the Deploy and Run Transactions button on the left side, which is the fourth button

4. In the Remix environment section, select Custom - External HTTP Provider and enter the GetBlock RPC endpoint URL you created for Opera

D) Create a smart contract

1. Click the File Explorer button on the left side on Remix, which is the first button

2. Right click and choose New File to create a new Solidity file

3. Enter the file name as "SimpleStorage.sol"

4. Copy and paste the following example Solidity code into the SimpleStorage.sol file:contract SimpleStorage {

E) Compile the smart contract

1. Click the Solidity Compiler button on the left side, which is the third button

2. Enable auto-compile for convenience

3. Click the Compile SimpleStorage.sol button

4. Check for the green sign indicating successful compilation

F) Deploy the smart contract on the Opera testnet using Remix

1. Click the Deploy and Run Transactions button on the left side, which is the fourth button

2. Select the SimpleStorage.sol contract from the dropdown menu

3. Click the Deploy button

4. Confirm the transaction in the MetaMask pop-up window

5. Once confirmed, you will see a message at the bottom right indicating the pending creation of the SimpleStorage contract

6. You can click on the transaction line or the debug button to view more details of the transaction

7. Copy the transaction hash for future reference

G) Use the Testnet Explorer

1. Use the to explore transactions and contracts on the Opera network

2. Paste the transaction hash into the search field at the top of the screen to view the details of your transaction

H) Interact with the deployed smart contract

1. In Remix, under the Deploy and Run Transactions section, expand the SimpleStorage contract by clicking the > symbol

2. The orange buttons represent functions that change information on the blockchain (state changes) and require gas to execute

3. The blue buttons represent read-only functions that do not modify the blockchain and do not require gas

• Get function

  1. Click the Get button to retrieve the stored value, but since we have not set any value yet, it will return the default value

• Set function

  • Enter a value in the field next to the Set button

  • Click the Set button

  • Confirm the transaction in the MetaMask pop-up window

  • Wait for the transaction to be confirmed

  • After confirmation, you can check the transaction details in the bottom-right section

Congratulations! You have learned how to use Remix, MetaMask, and GetBlock RPC endpoints to create and deploy a smart contract on Opera.

This guide demonstrates the compatibility of Ethereum developer tools with Opera, providing you with options for building decentralized applications on both platforms.

If you have any feedback or questions, you may ask them on the .

Types of API Nodes

Before you start your Opera API node, you need to decide which type you want to deploy based on your use case. There are two possible modes of operation:

• Pruned API Node Smaller database footprint utilizing around 700 GB of storage initially. It can respond to state-related RPC/socket requests, allows you to interact with the network state, trace smart contract execution, and submit signed transactions to the network. The state history is limited to the block from which the state DB is created, usually using a validator-type genesis file. If you try to query an older state, an error will be given.

• Archive API Node Larger database size using approximately 5.5 TB of storage initially. It can respond to all state-related RPC/socket requests for the whole blockchain history, allows you to interact with the network state at any block, trace smart contract execution, and submit signed transactions to the network. It's usually created from an archive genesis file.

Steps to Run API Node

1. Set up an Appropriate Server Instance

2. Install Required Development Tools

3. Build the Opera Node Software

4. Prime the Opera Database

5. Synchronize With the Network

1. Set up an Appropriate Server Instance

A dedicated hardware (also called bare metal) will provide the best possible performance and speed. If you want to integrate your node into a broader infrastructure of your project, you may want to consider a cloud service provider too. We recommend choosing one of the big cloud providers, e.g. Google GCP or Amazon AWS.

Node Hardware Specification

A minimal configuration for the Opera API node is a computation node with at least 4 vCPUs and 32 GB of RAM. You will also need either at least 1.2 TB or 7 TB of local NVMe storage space for the Opera database.

The proper size depends on your selected API node type. Remotely connected storage systems, e.g. Amazon EBS, usually don't provide the required latency and random access performance required to run an API node. The Google GCP N2D instances with local SSD drives, or Amazon AWS i3en.xlarge with the instance storage, match the minimal requirements.

The number of vCPUs and RAM available to the Opera node dictates the final performance and responsiveness of the API interface. Please scale the size of your server specification for the expected amount of RPC requests. We recommend instances with 8 vCPUs and 64 GB of RAM for smaller projects with less traffic, or 16 vCPUs and 128 GB of RAM for public API endpoints.

More RAM is needed to run "debug" API functionality in an RPC API node. For such a scenario, we recommend 128 GB.

Another option is to deploy several smaller nodes and load balance the incoming traffic between them. The deployment setup details suitable for your specific case may vary. We recommend using Ubuntu LTS Server (64-bit) or a similar Linux distribution.

Required Storage Capacity

• 1.2 TB of local NVMe/SSD storage is sufficient to start a pruned API node using a validator genesis file.

• 7 TB of local NVMe/SSD storage is needed to provision a full archive API node.

Obtain the latest genesis file.

Network Settings

The Opera node requires both TCP and UDP network traffic to be allowed on port 5050 by default. A custom port can be used with --port <port> flag when running your node.

The RPC/socket interface of the node can be opened for incoming HTTP traffic on port 80, but Opera does not support SSL/TLS encryption. You will need to add a proxy server between the public HTTP interface and the Opera node to be able to secure your connections with an SSL/TLS certificate.

Your cloud provider may offer a load-balanced application proxy solution, which includes certificate management. If you want to deploy such infrastructure yourself, you may want to check the HAProxy or Nginx community projects.

2. Install Required Development Tools

You need the essential building tools and Go compiler version 1.21 or newer to build the Opera client and bundled tools.

First, install the required build tools:

sudo apt-get install -y build-essential git

Install the latest Go compiler from binary distribution:

sudo rm -rf /usr/local/go
wget https://go.dev/dl/go1.22.4.linux-amd64.tar.gz
sudo tar -xzf go1.22.4.linux-amd64.tar.gz -C /usr/local/
rm -f go1.22.4.linux-amd64.tar.gz

Setup Go language export paths:

sudo tee /etc/profile.d/golang.sh > /dev/null <<EOT
export GOROOT=/usr/local/go
export GOPATH=\$HOME/go
export PATH=\$PATH:\$GOROOT/bin:\$GOPATH/bin

EOT

source /etc/profile.d/golang.sh

3. Build the Opera Node Software

Building the Opera binary requires the essential software development tools and the Go language version 1.21 or newer to be available. The previous section contains basic steps to deploy the required applications on the recommended Linux distribution. Please refer to your operating system manuals to install the development tools needed for this step.

Please check the latest release of the Opera node and adjust your commands accordingly.

git clone https://github.com/Fantom-foundation/Sonic.git
cd Sonic
git fetch --tags && git checkout -b v1.2.1-c tags/v1.2.1-c
make all

You can confirm the Opera release by executing the version subcommand on the created binary.

build/sonicd version

Optionally, you may want to copy the Opera node app and the tooling into the system-wide bin folder to make it available without explicitly specifying the binary path.

sudo mv build/sonic* /usr/local/bin/

4. Prime the Opera Database

You need a valid state database to be able to participate in the network. The fastest and easiest way is to use a genesis file. Please check the official repository, where new signed genesis files are published, and pick the latest one suitable for your selected node type. You will need approximately 50 GB of storage for a pruned genesis file and 350 GB of storage space for the full archive genesis download.

Obtain the latest genesis file and the corresponding checksum:

wget https://files.fantom.network/mainnet-285300-archive.g
wget https://files.fantom.network/mainnet-285300-archive.g.md5

Check your download using the MD5 checksum file:

$ md5sum --check mainnet-285300-archive.g.md5
mainnet-285300-archive.g: OK

Use the Opera tooling to prime the state database using the downloaded genesis file. Refer to these steps to determine the amount of cache and memory consumption soft limit for your node. The --datadir flag should point to your local NVMe storage mount path.

GOMEMLIMIT=58GiB sonictool \
    --datadir ~/.sonic \
    --cache 25600 \
    genesis mainnet-285300-archive.g

The Opera tool creates a primed state database from the genesis file. The last step is a validation procedure. It confirms that the expected state was built successfully reaching the expected root hash. You can refer to the official repository to verify that the state hash is indeed correct.

StateDB imported successfully, stateRoot matches module=gossip-store
  index=81990246 root="f60cd4…38652f"

Calculate Cache Size and Memory Consumption Soft Limit Values

The Opera node utilizes a large amount of RAM to achieve great speed and responsiveness. It should be the only user-space application consuming your system resources.

$ grep MemTotal /proc/meminfo
MemTotal:       65641928 kB

• Approximately 40% of the available RAM should be used as the --cache for both the sonictool and sonicd applications. The final value is denominated in MiB. For example: 64,000 MiB RAM * 40% = 25,600 MiB.

• Approximately 90% of the available RAM should be used as the application memory consumption limit. This limit is controlled by theGOMEMLIMIT environment variable. The final value includes abbreviated units. We recommend using GiB for simplicity. For example: 64 GiB RAM * 90% ≈ 58 GiB.

5. Synchronize With the Network

Your node database has been primed to a certain epoch in the past using a genesis file and the Opera tool. Now you need to get the node up to the current state.

To do it, your node needs to be started in the read-only mode and establish a connection with the network.Please make sure your firewall is configured correctly to allow such communication. The amount of memory dedicated to the node cache and the memory consumption limit are outlined above.

The RPC and/or socket interfaces are turned off by default. You need to specify which one you want to start and what range of services you want it to offer. You can find the default configuration in the example below. Please adjust the port, namespace, and domain-related options based on your specific needs.

The HTTP API offers the Web3 interface for the request-response type of interaction with the Opera chain. The WS API supports a sustained network connection with the ability to subscribe to certain network events, e.g. new blocks being created or contracts being interacted with.

GOMEMLIMIT=58GiB sonicd \
    --datadir ~/.sonic \
    --cache 25600 \
    --http \
    --http.addr=0.0.0.0 \
    --http.port=8080 \
    --http.corsdomain="*" \
    --http.vhosts="*" \
    --http.api=eth,web3,net,ftm,txpool,abft,dag \
    --ws \
    --ws.addr=0.0.0.0 \
    --ws.port=8081 \
    --ws.origins="*" \
    --ws.api=eth,web3,net,ftm,txpool,abft,dag

The Opera node should start and connect with the network, advancing the state by creating and processing new blocks. Please notice the age part of the log message, which tells you how far in the past these blocks are. The age should not exceed a couple of seconds once the node is fully synchronized.

Storing wallets on managed servers is not recommended, and it is advised to use only unmanaged servers for running validator nodes.

However, if you prefer to run a validator node using a provider rather than your own hardware, you can find a comprehensive list of providers below that offer the setup of an Opera node.

Managed Node Providers

List provided by CompareNodes.

Cloud Providers

• Amazon AWS (+)

• Digital Ocean

• Google GCP

• Microsoft Azure

Bare Metal Providers

Gathered from the community's suggestions.

• Vultr

• OVH

• Webtropia

• Leaseweb

• Latitude

Introduction

Chainlink enables smart contracts on Opera to leverage extensive off-chain resources, such as tamper-proof price data, verifiable randomness, external APIs, and much more. This documentation describes access to various cryptocurrency price data available to be integrated into decentralized applications running on Opera.

• For implementation instructions, please refer to

• For LINK token and faucet details, please refer to .

Note, off-chain equity and ETF assets are only traded during standard market hours (9:30 AM – 4:00 PM ET Monday–Friday). Using these feeds outside of those windows is not recommended.

Supported Token Pairs

Currently, the list of supported symbols can be found below. Going forward, this list will continue to expand based on developer needs and community feedback.

Opera Mainnet

Opera Testnet

Querying Prices

Currently, there are two methods for developers to query prices from the Chainlink data feed: Through the Solidity PriceConsumer smart contract running on the hosting blockchain and through an external interface utilizing Chainlink AggregatorInterface ABI.

Solidity

To consume price data, your smart contract should reference , which defines the external functions implemented by Price Feeds. The latest RoundData function returns five values representing information about the latest price data. See Price Feeds API Reference for more details.

Introduction

Getting historical data on a smart contract can be frustrating when you’re building a dApp. The Graph provides an easy and decentralized option to query smart contract data through APIs known as subgraphs. Its infrastructure relies on a decentralized network of indexers, enabling your dApp to achieve true decentralization.

These subgraphs only take a few minutes to set up. To get started, follow these three steps:

All developers receive 100k free queries per month on the decentralized network. After these free queries, you only pay based on usage at $4 for every 100k queries.

1. Initialize Your Subgraph Project

Create a Subgraph on Subgraph Studio⁠

Go to the and connect your wallet. Once your wallet is connected, you can begin by clicking Create a Subgraph. When choosing a name for your subgraph, it is recommended to use title case, e.g. “Subgraph Name Chain Name.”

You will then land on your subgraph’s page. All the CLI commands you need will be visible on the right side of the page:

Install the Graph CLI⁠

On your local machine run the following:

Initialize your Subgraph⁠

You can copy this directly from your subgraph page to include your specific subgraph slug:

You’ll be prompted to provide some info on your subgraph like this:

Simply have your contract verified on the block explorer and the CLI will automatically obtain the ABI and set up your subgraph. The default settings will generate an entity for each event.

2. Deploy and Publish

Deploy to Subgraph Studio⁠

First, run these commands:

Then run these to authenticate and deploy your subgraph. You can copy these commands directly from your subgraph’s page in Studio to include your specific deploy key and subgraph slug:

You will be asked for a version label. You can enter something like v0.0.1, but you’re free to choose the format.

Test Your Subgraph⁠

You can test your subgraph by making a sample query in the playground section. The Details tab will show you an API endpoint. You can use that endpoint to test from your dApp.

Publish Your Subgraph to The Graph’s Decentralized Network

Once your subgraph is ready to be put into production, you can publish it to the decentralized network. On your subgraph’s page in Subgraph Studio, click on the Publish button:

Before you can query your subgraph, Indexers need to begin serving queries on it. To streamline this process, you can curate your own subgraph using GRT.

When publishing, you’ll see the option to curate your subgraph. As of May 2024, it is recommended that you curate your own subgraph with at least 3,000 GRT to ensure that it is indexed and available for querying as soon as possible.

3. Query Your Subgraph

Congratulations! You can now query your subgraph on the decentralized network!

For any subgraph on the decentralized network, you can start querying it by passing a GraphQL query into the subgraph’s query URL which can be found at the top of its Explorer page.

Here’s an example from the by Messari:

The query URL for this subgraph is:

Now, you simply need to fill in your own API Key to start sending GraphQL queries to this endpoint.

Getting Your Own API Key

In Subgraph Studio, you’ll see the API Keys menu at the top of the page. Here you can create API Keys.

Appendix

Sample Query

This query shows the most expensive CryptoPunks sold:

Passing this into the query URL returns this result:

Sample Code

Additional Resources:

• To explore all the ways you can optimize and customize your subgraph for better performance, read more about .

• For more information about querying data from your subgraph, read more .

Images used in this article are sourced from .

Introduction

Developers building on Opera can now leverage Band Protocol’s decentralized oracle infrastructure. With Band’s oracles, they now have access to various cryptocurrency price data to integrate into their applications.

Supported Tokens

Currently, the list of supported symbols can be found below. Going forward, this list will continue to expand based on developer needs and community feedback.

Price Pairs

The methods in the following sections can work with any combination of base/quote token pairs, as long as the base and quote symbols are supported by the dataset.

Querying Prices

Currently, there are two methods for developers to query prices from Band’s oracle: through Band’s StdReference smart contract on BSC and through their bandchain.js JavaScript helper library.

Solidity Smart Contract

To query prices from Band’s oracle, a smart contract should reference Band’s StdReference contract, specifically the getReferenceData and getReferenceDatabulk methods.

getReferenceData takes two strings as the inputs, the base and quote symbol, respectively. It then queries the StdReference contract for the latest rates for those two tokens and returns a ReferenceData struct, shown below.

struct ReferenceData {
    uint256 rate; // base/quote exchange rate, multiplied by 1e18.
    uint256 lastUpdatedBase; // UNIX epoch of the last time when base price gets updated.
    uint256 lastUpdatedQuote; // UNIX epoch of the last time when quote price gets updated.
}

getReferenceDataBulk instead takes two lists, one of the base tokens, and one of the quotes. It then proceeds to similarly queries the price for each base/quote pair at each index, and returns an array of ReferenceData structs.

For example, if we call getReferenceDataBulk with ['BTC','BTC','ETH'] and ['USD','ETH','BNB'], the returned ReferenceData array will contain information regarding the pairs:

• BTC/USD

• BTC/ETH

• ETH/BNB

Contract Addresses

Example Usage

This contract demonstrates an example of using Band’s StdReference contract and the getReferenceData function.

BandChain.JS

Band’s node helper library bandchain.js also supports a similar getReferenceData function. This function takes one argument, a list of token pairs to query the result. It then returns a list of corresponding rate values.

Example Usage

The code below shows an example usage of the function:

const { Client } = require('@bandprotocol/bandchain.js');

// BandChain's REST Endpoint
const endpoint = 'https://rpc.bandchain.org';
const client = new Client(endpoint);

// This example demonstrates how to query price data from
// Band's standard dataset
async function exampleGetReferenceData() {
  const rate = await client.getReferenceData(['BTC/ETH','BAND/EUR', 'FTM/USD']);
  return rate;
}

(async () => {
  console.log(await exampleGetReferenceData());
})();

The corresponding result will then be similar to:

$ node index.js
[ 
    { 
        pair: 'BTC/ETH',
        rate: 30.998744363906173,
        updatedAt: { base: 1615866954, quote: 1615866954 },
        requestID: { base: 2206590, quote: 2206590 } 
    },
    { 
        pair: 'BAND/EUR',
        rate: 10.566138918332376,
        updatedAt: { base: 1615866845, quote: 1615866911 },
        requestID: { base: 2206539, quote: 2206572 } 
    }, 
    { 
        pair: 'FTM/USD',
        rate: 0.36662363,
        updatedAt: { base: 1615866851, quote: 1615866960 },
        requestID: { base: 2206543, quote: 0 } 
    }
]

For each pair, the following information will be returned:

• pair: The base/quote symbol pair string.

• rate: The resulting rate of the given pair.

• updated: The timestamp at which the base and quote symbols were last updated on BandChain. For USD, this will be the current timestamp.

• rawRate: This object consists of two parts.

  • value is the BigInt value of the actual rate, multiplied by 10^decimals.

  • decimals is then the exponent by which rate was multiplied by to get rawRate.

Validator Parameters

• Minimum stake: 50,000 FTM.

• Minimum hardware requirements: AWS EC2 m5.large with 8GB RAM, 2 vCPUs, and at least 300 GB of Amazon EBS General Purpose SSD (gp3) storage (or equivalent).

• We would recommend going with Ubuntu Server 22.04 LTS (64-bit).

Network Settings

Open up port 22 for SSH, as well as port 7946 for both TCP and UDP traffic. A custom port can be used with "--port <port>" flag when running your testnet node.

Steps to Run Validator

1. Install Required Tools

You are still logged in as the new user via SSH. Now we are going to install Go and Opera.

First, install the required build tools:

Install Opera:

Validate your Opera installation:

db.preset

When using version 1.1.3, you need to add the db.preset argument (introduced since 1.1.2) for starting the Opera command. For standard conditions, please use this option:

• db.preset=ldb-1

You can use different db presets, either --db.preset ldb-1 or --db.preset legacy-db. It's not recommended to use pbl-1 for validator nodes.

2. Register Testnet Validator

Next, register your Opera testnet validator node. You need to create a validator wallet. The wallet is the validator’s identity on the network, which it uses to authenticate, sign messages, etc.

First, start the Opera read-only node and download a genesis file from this .

3. Create a Validator Wallet

The node is currently running and syncing the network in your console. To create a wallet, open a new console window, connect to the server via SSH, and enter the following commands.:

After entering the command, you will get prompted to enter a password for the account. It will look something like this:

4. Create a New Validator Key

We have to create a validator private key with which to sign consensus messages. It can be done only using go-opera:

Follow the prompts and supply the password. The output is as follows:

5. Create Your Validator via The SFC

You should wait for your node to sync to the latest block of the network before proceeding. To proceed, open up the console where you entered the commands to create the validator wallet previously and attach it to the Opera node console:

By doing so, you will get a JavaScript console where you can directly interact with the Opera node and e.g. send transactions (which you will do in a moment):

Now initialize the SFC contract ABI variable:

Also, initialize the SFC contract object itself:

After initializing both variables, you can now interact with the network’s SFC. Enter the following command to check that everything works as expected:

If it looks like the above, everything is working. Next, try to get your validator ID from the SFC using your previously generated validator wallet address:

This should return "0" as you are not registered as a validator yet: Next, unlock your validator wallet to be able to execute the registration transaction (make sure to use the password you set before):

This will return “true” if unlocking the wallet was successful: Next, send the createValidator transaction to register your validator (the value is the representation of the smallest FTM unit, so dividing it by 1e18 will result in 500,000 FTM. Alternatively, you can use web3.toWei("500000.0", "ftm")). Use quotes for "0xYOUR_PUBKEY" and "0xYOUR_ADDRESS":

Make sure to check your registration transaction (could take a few moments to be confirmed):

Look for the status: “0x1” at the bottom, which means the transaction was successful. You can also copy the transaction hash and go to the Fantom Explorer and check your transaction there:

https://explorer.testnet.fantom.network/transactions/[YOURTX]

Finally, execute the following command again to check your validator ID:

It should now return something other than “0”. Congrats, you've registered a testnet validator!

6. Run Your Testnet Validator Node

The last step is to restart your node in validator mode! Close the Opera console window by typing “exit”. Then head back to the console window where you started your node with the following command:

For the latest update, please check .