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.

fWallet 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

• Stake and delegate FTM

• Claim staking rewards

• Create and vote on governance proposals

• Swap tokens, powered by OpenOcean

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

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: https://testnet.ftmscan.com/

You can access the Opera Testnet Faucet for some free testnet FTM.

This documentation offers comprehensive details on using and developing applications on our 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.

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 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 testnet faucet.

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 example given here.

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

• Compiling

• Deploying a Smart Contract on Ethereum

Tools

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

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

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

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

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

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

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

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 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.

Liquid staking on Opera allows users to unlock liquidity from staked assets, opening new opportunities within DeFi. Traditionally, if you stake FTM, 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: Beethoven X and Ankr Protocol. 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 Beethoven X’s sFTMx page

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. Learn more here 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 Ankr’s FTM Liquid Staking page

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 Ankr Staking dashboard, 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. Learn more here about liquid staking on Ankr.

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

Unit Testing in 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

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

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

Create the Asset

1. Write the token smart contract:

   1. https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol

   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 the Explorer to check that your token has been created

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

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

Introduction

First-Party Oracles

Using dAPIs — API3 Datafeeds

Subscribing to dAPIs

Exploring, Selecting, and Configuring Your 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.

Additional Resources

Here are some additional developer resources:

Introduction

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

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.

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

BandChain.JS

Example Usage

The code below shows an example usage of the function:

The corresponding result will then be similar to:

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.

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.

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

Signing a Transaction

Here’s an example of signing a transaction to update the blockchain state by creating a transaction. This example 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 two methods 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:

• https://github.com/Fantom-foundation/web3-methods/wiki

Transfer

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

transfer

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

transferWithParams

This method transfers with additional parameters in its transaction block.

// Change maxFeePerGas and maxPriorityFeePerGas as per the current gas prices
var transaction = {
    to: TO_ADDRESS,
    from: address,
    nonce: nonceVal,
    value: testWeb3.utils.toHex(testWeb3.utils.toWei('0.1', 'ether')),
    gas: testWeb3.utils.toHex(21000),
    maxFeePerGas: '0x174876E800', // 100 Gwei 
    maxPriorityFeePerGas: '0xBA43B7400', // 50 Gwei
    chainId
};

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.

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 MongoDB database installation.

• Go version 1.13 or later configured and ready.

• Lachesis full node 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 Go modules. Instead, use any other location.

$ git clone https://github.com/Fantom-foundation/fantom-api-graphql.git

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

$ cd fantom-api-graphql
$ go build -o ./build/apiserver ./cmd/apiserver

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

$ build/apiserver

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:

server:
    bind: 127.0.0.1:16761    
lachesis:
    url: /var/opera/data/lachesis.ipc
log:
    level: Debug
mongo:
    url: mongodb://127.0.0.1:27017
cors:
    origins: *

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.

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

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.

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.

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.

import "@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol";

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

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

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

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.

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

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

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.

Full schema of the GraphQL API is:

# Hash is a 32 byte binary string, represented by 0x prefixed hexadecimal.
scalar Hash

# Address is a 20 byte Opera address, represented as 0x prefixed hexadecimal number.
scalar Address

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

# Long is a 64 bit unsigned integer value.
scalar Long

# Bytes is an arbitrary length binary string, represented as 0x-prefixed hexadecimal.
# An empty byte string is represented as '0x'.
scalar Bytes

# Cursor is a string representing position in a sequential list of edges.
scalar Cursor

# Root schema definition
schema {
    query: Query
    mutation: Mutation
    subscription: Subscription
}

# Entry points for querying the API
type Query {
    "Total number of accounts active on the Opera blockchain."
    accountsActive:Long!

    "Get an Account information by hash address."
    account(address:Address!):Account!

    """
    Get list of Contracts with at most <count> edges.
    If <count> is positive, return edges after the cursor,
    if negative, return edges before the cursor.
    For undefined cursor, positive <count> starts the list from top,
    negative <count> starts the list from bottom.
    ValidatedOnly specifies if the list should contain all the Contracts,
    or just contracts with validated byte code and available source/ABI.
    """
    contracts(validatedOnly: Boolean = false, cursor:Cursor, count:Int!):ContractList!

    """
    Get block information by number or by hash.
    If neither is provided, the most recent block is given.
    """
    block(number:Long, hash: Hash):Block

    "Get transaction information for given transaction hash."
    transaction(hash:Hash!):Transaction

    """
    Get list of Blocks with at most <count> edges.
    If <count> is positive, return edges after the cursor,
    if negative, return edges before the cursor.
    For undefined cursor, positive <count> starts the list from top,
    negative <count> starts the list from bottom.
    """
    blocks(cursor:Cursor, count:Int!):BlockList!

    """
    Get list of Transactions with at most <count> edges.
    If <count> is positive, return edges after the cursor,
    if negative, return edges before the cursor.
    For undefined cursor, positive <count> starts the list from top,
    negative <count> starts the list from bottom.
    """
    transactions(cursor:Cursor, count:Int!):TransactionList!

    "Get the id of the current epoch of the Opera blockchain."
    currentEpoch:Long!

    """
    Get information about specified epoch. Returns current epoch information
    if id is not provided.
    """
    epoch(id: Long!): Epoch!

    "The last staker id in Opera blockchain."
    lastStakerId: Long!

    "The number of stakers in Opera blockchain."
    stakersNum: Long!

    """
    Staker information. The staker is loaded either by numeric ID,
    or by address. null if none is provided.
    """
    staker(id: Long, address: Address): Staker

    "List of staker information from SFC smart contract."
    stakers: [Staker!]!

    """
    The list of delegations for the given staker ID.
    Cursor is used to obtain specific slice of the staker's delegations.
    The most recent delegations are provided if cursor is omitted.
    """
    delegationsOf(staker:Long!, cursor: Cursor, count: Int = 25): DelegatorList!

    "Get the details of a delegator by it's address."
    delegation(address:Address!): Delegator

    "Returns the current price per gas in WEI units."
    gasPrice: Long!

    "Get price details of the Opera blockchain token for the given target symbols."
    price(to:String!):Price!

    """
    Get calculated staking rewards for an account or given
    staking amount in FTM tokens.
    At least one of the address and amount parameters must be provided.
    If you provide both, the address takes precedence and the amount is ignored.
    """
    estimateRewards(address:Address, amount:Long):EstimatedRewards!
}

# Mutation endpoints for modifying the data
type Mutation {
    """
    SendTransaction submits a raw signed transaction into the block chain.
    The tx parameter represents raw signed and RLP encoded transaction data.
    """
    sendTransaction(tx: Bytes!):Transaction

    """
    Validate a deployed contract byte code with the provided source code
    so potential users can check the contract source code, access contract ABI
    to be able to interact with the contract and get the right metadata.
    Returns updated contract information. If the contract can not be validated,
    it raises a GraphQL error.
    """
    validateContract(contract: ContractValidationInput!): Contract!
}

# Subscriptions to live events broadcasting
type Subscription {
    "Subscribe to receive information about new blocks in the blockchain."
    onBlock: Block!

    "Subscribe to receive information about new transactions in the blockchain."
    onTransaction: Transaction!
}


# StakerInfo represents extended staker information from smart contract.
type StakerInfo {
    "Name represents the name of the staker."
    name: String

    "LogoUrl represents staker logo URL."
    logoUrl: String

    "Website represents a link to stakers website."
    website: String

    "Contact represents a link to contact to the staker."
    contact: String
}

# DelegatorList is a list of delegations edges provided by sequential access request.
type DelegatorList {
    "Edges contains provided edges of the sequential list."
    edges: [DelegatorListEdge!]!

    """
    TotalCount is the maximum number of delegations
    available for sequential access.
    """
    totalCount: BigInt!

    "PageInfo is an information about the current page of delegation edges."
    pageInfo: ListPageInfo!
}

# BlockListEdge is a single edge in a sequential list of blocks.
type DelegatorListEdge {
    "Cursor defines a scroll key to this edge."
    cursor: Cursor!

    "Delegator represents the delegator provided by this list edge."
    delegator: Delegator!
}

# Delegator represents a delegation on Opera blockchain.
type Delegator {
    "Address of the delegator account."
    address: Address!

    "Identifier of the staker the delegation belongs to."
    toStakerId: Long!

    "Epoch in which the delegation was made."
    createdEpoch: Long!

    "Timestamp of the delegation creation."
    createdTime: Long!

    "Epoch in which the delegation was deactivated."
    deactivatedEpoch: Long

    "Timestamp of the deactivation of the delegation."
    deactivatedTime: Long

    "Amount delegated. It includes all the pending un-delegations."
    amount: BigInt!

    """
    Amount delegated. The current amount still registered
    by SFC contract as delegated amount. It does include pending
    deactivation, but does not include partial un-delegations.
    """
    amountDelegated: BigInt
    
    "Amount locked in pending un-delegations and withdrawals."
    amountInWithdraw: BigInt!

    "Amount of rewards claimed."
    claimedReward: BigInt

    "Pending rewards for the delegation."
    pendingRewards: PendingRewards!

    "List of withdraw requests of the delegation."
    withdrawRequests: [WithdrawRequest!]!

    "List of full delegation deactivation."
    deactivation: [DeactivatedDelegation!]!
}

# Account defines block-chain account information container
type Account {
    "Address is the address of the account."
    address: Address!

    "Balance is the current balance of the Account in WEI."
    balance: BigInt!

    """
    TotalValue is the current total value fo the account in WEI.
    It includes available balance,
    delegated amount and pending staking rewards.
    """
    totalValue: BigInt!

    "txCount represents number of transaction sent from the account."
    txCount: Long!

    """
    txList represents list of transactions of the account
    in form of TransactionList.
    """
    txList (cursor:Cursor, count:Int!): TransactionList!

    "Details of a staker, if the account is a staker."
    staker: Staker

    "Details of delegation, if the account is a delegator."
    delegation: Delegator

    "Details about smart contract, if the account is a smart contract."
    contract: Contract
}

# EstimatedRewards represents a calculated rewards estimation for an account or amount staked
type EstimatedRewards {
    "Amount of FTM tokens expected to be staked for the calculation."
    staked: Long!

    """
    dailyReward represents amount of FTM tokens estimated
    to be rewarded for staked amount in average per day.
    """
    dailyReward: BigInt!

    """
    weeklyReward represents amount of FTM tokens estimated
    to be rewarded for staked amount in average per week.
    """
    weeklyReward: BigInt!

    """
    monthlyReward represents amount of FTM tokens estimated
    to be rewarded for staked amount in average per month.
    """
    monthlyReward: BigInt!

    """
    yearlyReward represents amount of FTM tokens estimated
    to be rewarded for staked amount in average per year.
    """
    yearlyReward: BigInt!

    """
    currentRewardYearRate represents average reward rate
    for any staked amount in average per year.
    The value is calculated as linear gross proceeds for staked amount
    of tokens yearly.
    """
    currentRewardRateYearly: Int!

    """
    Total amount of staked FTM tokens used for the calculation in WEI units.
    The estimation uses total staked amount, not the effective amount provided
    by the last epoch. The effective amount does include current
    un-delegations and also skips offline self-staking and flagged staking.
    """
    totalStaked: BigInt!

    """
    Information about the last sealed epoch of the Opera blockchain.
    The epoch provides useful information about total FTM supply,
    total amount staked, rewards rate and weight, fee, etc.
    """
    lastEpoch: Epoch!
}

# TransactionList is a list of transaction edges provided by sequential access request.
type TransactionList {
    # Edges contains provided edges of the sequential list.
    edges: [TransactionListEdge!]!

    # TotalCount is the maximum number of transactions available for sequential access.
    totalCount: BigInt!

    # PageInfo is an information about the current page of transaction edges.
    pageInfo: ListPageInfo!
}

# TransactionListEdge is a single edge in a sequential list of transactions.
type TransactionListEdge {
    cursor: Cursor!
    transaction: Transaction!
}

# Transaction is an Opera block chain transaction.
type Transaction {
    # Hash is the unique hash of this transaction.
    hash: Hash!

    # Nonce is the number of transactions sent by the account prior to this transaction.
    nonce: Long!

    # Index is the index of this transaction in the block. This will
    # be null if the transaction is in a pending pool.
    index: Long

    # From is the address of the account that sent this transaction
    from: Address!

    # Sender is the account that sent this transaction
    sender: Account!

    # To is the account the transaction was sent to.
    # This is null for contract creating transactions.
    to: Address

    # contractAddress represents the address of smart contract deployed by this transaction;
    # null if the transaction is not contract creation
    contractAddress: Address

    # Recipient is the account that received this transaction.
    # Null for contract creating transaction.
    recipient: Account

    # Value is the value sent along with this transaction in WEI.
    value: BigInt!

    # GasPrice is the price of gas per unit in WEI.
    gasPrice: BigInt!

    # Gas represents gas provided by the sender.
    gas: Long!

    # GasUsed is the amount of gas that was used on processing this transaction.
    # If the transaction is pending, this field will be null.
    gasUsed: Long

    # InputData is the data supplied to the target of the transaction.
    # Contains smart contract byte code if this is contract creation.
    # Contains encoded contract state mutating function call if recipient
    # is a contract address.
    inputData: Bytes!

    # BlockHash is the hash of the block this transaction was assigned to.
    # Null if the transaction is pending.
    blockHash: Hash

    # BlockHash is the hash of the block this transaction was assigned to.
    # Null if the transaction is pending.
    blockNumber: Long

    # Block is the block this transaction was assigned to. This will be null if
    # the transaction is pending.
    block: Block

    # Status is the return status of the transaction. This will be 1 if the
    # transaction succeeded, or 0 if it failed (due to a revert, or due to
    # running out of gas). If the transaction has not yet been processed, this
    # field will be null.
    status: Long
}

# Represents epoch information.
type Epoch {
    "Number the epoch end."
    id: Long!

    "Timestamp of the epoch end."
    endTime: BigInt!

    "Epoch duration in seconds."
    duration: BigInt!

    "Fee at the epoch."
    epochFee: BigInt!

    "Total base reward weight on epoch."
    totalBaseRewardWeight: BigInt!

    "Total transaction reward weight on epoch."
    totalTxRewardWeight: BigInt!

    "Base reward per second of epoch."
    baseRewardPerSecond: BigInt!

    "Total amount staked."
    stakeTotalAmount: BigInt!

    "Total amount delegated."
    delegationsTotalAmount: BigInt!

    "Total supply amount."
    totalSupply: BigInt!
}

# ContractList is a list of smart contract edges provided by sequential access request.
type ContractList {
    # Edges contains provided edges of the sequential list.
    edges: [ContractListEdge!]!

    # TotalCount is the maximum number of contracts available for sequential access.
    totalCount: BigInt!

    # PageInfo is an information about the current page of contract edges.
    pageInfo: ListPageInfo!
}

# TransactionListEdge is a single edge in a sequential list of transactions.
type ContractListEdge {
    cursor: Cursor!
    contract: Contract!
}

# Price represents price information of core Opera token
type Price {
    "Source unit symbol."
    fromSymbol: String!

    "Target unit symbol."
    toSymbol: String!

    "Price of the source symbol unit in target symbol unit."
    price: Float!

    "Price change in last 24h."
    change24: Float!

    "Price change in percent in last 24h."
    changePct24: Float!

    "Open 24h price."
    open24: Float!

    "Highest 24h price."
    high24: Float!

    "Lowest 24h price."
    low24: Float!

    "Volume exchanged in last 24h price."
    volume24: Float!

    "Market cap of the source unit."
    marketCap: Float!

    "Timestamp of the last update of this price value."
    lastUpdate: Long!
}

# Represents staker information.
type Staker {
    "Id number the staker."
    id: Long!

    "Staker address."
    stakerAddress: Address!

    "Amount of total staked tokens in WEI."
    totalStake: BigInt

    "Amount of own staked tokens in WEI."
    stake: BigInt

    "Amount of tokens delegated to the staker in WEI."
    delegatedMe: BigInt

    """
    Maximum total amount of tokens allowed to be delegated
    to the staker in WEI.
    This value depends on the amount of self staked tokens.
    """
    totalDelegatedLimit: BigInt!

    """
    Maximum amount of tokens allowed to be delegated to the staker
    on a new delegation in WEI.
    This value depends on the amount of self staked tokens.
    """
    delegatedLimit: BigInt!

    "Is this a validator record."
    isValidator: Boolean!

    "Is the staker active."
    isActive: Boolean!

    "Is the staker considered to be cheater."
    isCheater: Boolean!

    "Is the staker offline."
    isOffline: Boolean!

    "Epoch in which the staker was created."
    createdEpoch: Long!

    "Timestamp of the staker creation."
    createdTime: Long!

    "Epoch in which the staker was deactivated."
    deactivatedEpoch: Long!

    "Timestamp of the staker deactivation."
    deactivatedTime: Long!

    "How many blocks the staker missed."
    missedBlocks: Long!

    "Number of seconds the staker is offline."
    downtime: Long!

    "Proof of importance score."
    poi: BigInt

    "Base weight for rewards distribution."
    baseRewardWeight: BigInt

    "Weight for transaction rewards distribution."
    txRewardWeight: BigInt

    "Validation score."
    validationScore: BigInt

    "Origination score."
    originationScore: BigInt

    "Amount of rewards claimed in WEI."
    claimedRewards: BigInt

    "Amount of rewards claimed by delegators in WEI."
    delegationClaimedRewards: BigInt

    """
    List of delegations of this staker. Cursor is used to obtain specific slice
    of the staker's delegations. The most recent delegations
    are provided if cursor is omitted.
    """
    delegations(cursor: Cursor, count: Int = 25):DelegatorList!

    """
    Status is a binary encoded status of the staker.
    Ok = 0, bin 1 = Fork Detected, bin 256 = Validator Offline
    """
    status: Long!

    "StakerInfo represents extended staker information from smart contract."
    stakerInfo: StakerInfo

    """
    List of withdraw requests of the stake.
    Contains only withdrawal requests of the staking account,
    not the requests of the stake delegators.
    """
    withdrawRequests: [WithdrawRequest!]!
}

# PendingRewards represents a detail of pending rewards for staking and delegations
type PendingRewards {
    "Pending rewards amount."
    amount: BigInt!

    "The first unpaid epoch."
    fromEpoch: Long!

    "The last unpaid epoch."
    toEpoch: Long!
}

# WithdrawRequest represents a request for partial stake withdraw.
type WithdrawRequest {
    "Address of the authorized request."
    address: Address!

    "Address of the receiving account."
    receiver: Address!

    "Account receiving the withdraw request."
    account: Account!

    "Staker Id of the staker involved in the withdraw request."
    stakerID: Long!

    "Details of the staker involved in the withdraw request."
    staker: Staker!

    "Unique withdraw request identifier."
    withdrawRequestID: BigInt!

    "Is this a partial delegation withdraw, or staker withdraw?"
    isDelegation: Boolean!

    "Amount of WEI requested to be withdrawn."
    amount: BigInt!

    "Block in which the withdraw request was registered."
    requestBlock: Block!

    """
    Block in which the withdraw request was finalized.
    The value is NULL for pending request.
    """
    withdrawBlock: Block

    """
    Amount of WEI slashed as a penalty for cheating.
    The penalty is applied not only to staker withdraw,
    but also to delegations of a cheating staker.
    The value is NULL for pending requests.
    """
    withdrawPenalty: BigInt
}

# DeactivatedDelegation represents a prepared delegation full withdraw.
# Fully withdrawn delegations must be prepared first and finalized
# only after the lock down period passes.
type DeactivatedDelegation {
    "Address of the delegator."
    address: Address!

    "Staker Id of the staker involved in the withdraw request."
    stakerID: Long!

    "Details of the staker involved in the withdraw request."
    staker: Staker!

    "Block in which the delegation deactivation was registered."
    requestBlock: Block!

    """
    Block in which the delegation was withdrawn.
    The value is NULL for pending request.
    """
    withdrawBlock: Block

    """
    Amount of WEI slashed as a penalty for cheating.
    The penalty is applied to delegators' rewards
    in case their staker is flagged.
    The value is NULL for pending requests.
    """
    withdrawPenalty: BigInt
}

# Block is an Opera block chain block.
type Block {
    # Number is the number of this block, starting at 0 for the genesis block.
    number: Long!

    # Hash is the unique block hash of this block.
    hash: Hash!

    # Parent is the parent block of this block.
    parent: Block

    # TransactionCount is the number of transactions in this block.
    transactionCount: Int

    # Timestamp is the unix timestamp at which this block was mined.
    timestamp: Long!

    # txHashList is the list of unique hash values of transaction
    # assigned to the block.
    txHashList: [Hash!]!

    # txList is a list of transactions assigned to the block.
    txList: [Transaction!]!
}

# Contract defines block-chain smart contract information container
type Contract {
    "Address represents the contract address."
    address: Address!

    "DeployedBy represents the smart contract deployment transaction reference."
    deployedBy: Transaction!

    "transactionHash represents the smart contract deployment transaction hash."
    transactionHash: Hash!

    "Smart contract name. Empty if not available."
    name: String!

    "Smart contract version identifier. Empty if not available."
    version: String!

    """
    License specifies an open source license the contract was published with.
    Empty if not specified.
    """
    license: String!

    "Smart contract author contact. Empty if not available."
    supportContact: String!

    "Smart contract compiler identifier. Empty if not available."
    compiler: String!

    "Smart contract source code. Empty if not available."
    sourceCode: String!

    "Smart contract ABI definition. Empty if not available."
    abi: String!

    """
    Validated is the unix timestamp at which the source code was validated
    against the deployed byte code. Null if not validated yet.
    """
    validated: Long

    "Timestamp is the unix timestamp at which this smart contract was deployed."
    timestamp: Long!
}

# ContractValidationInput represents a set of data sent from client
# to validate deployed contract with the provided source code.
input ContractValidationInput {
    "Address of the contract being validated."
    address: Address!

    "Optional smart contract name. Maximum allowed length is 64 characters."
    name: String

    "Optional smart contract version identifier. Maximum allowed length is 14 characters."
    version: String

    "Optional smart contract author contact. Maximum allowed length is 64 characters."
    supportContact: String

    """
    License specifies an open source license the contract was published with.
    Empty if not specified.
    """
    license: String

    "Optimized specifies if the compiler was set to optimize the byte code."
    optimized: Boolean = true

    """
    OptimizeRuns specifies number of optimization runs the compiler was set
    to execute during the byte code optimizing.
    """
    optimizeRuns: Int = 200

    "Smart contract source code."
    sourceCode: String!
}

# BlockList is a list of block edges provided by sequential access request.
type BlockList {
    # Edges contains provided edges of the sequential list.
    edges: [BlockListEdge!]!

    # TotalCount is the maximum number of blocks available for sequential access.
    totalCount: BigInt!

    # PageInfo is an information about the current page of block edges.
    pageInfo: ListPageInfo!
}

# BlockListEdge is a single edge in a sequential list of blocks.
type BlockListEdge {
    cursor: Cursor!
    block: Block!
}

# ListPageInfo contains information about a sequential access list page.
type ListPageInfo {
    # First is the cursor of the first edge of the edges list. null for empty list.
    first: Cursor

    # Last if the cursor of the last edge of the edges list. null for empty list.
    last: Cursor

    # HasNext specifies if there is another edge after the last one.
    hasNext: Boolean!

    # HasNext specifies if there is another edge before the first one.
    hasPrevious: Boolean!
}

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.

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

1. Go to FTMScan Verify Contract.

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 https://abi.hashex.org/. 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 FTMScan 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:

npx hardhat verify --contract contracts/YourContractFile.sol:YourContractName --constructor-args scripts/argument.js --network testnet {contract address}

truffle run verify YourContract@{contract address} --network testnet

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 Hardhat documentation.

• 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. Here is an example.

Create Contract

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

1. In your CLI run the following command:
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
3. Once created, navigate to your project’s directory and open in your preferred code editor.

4. 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.

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

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:

   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.

Deploy an Opera Testnet Node

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

Install Foundry

Foundry is a development toolkit to work with smart contracts.

Initialize With Foundry

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

Fund Your Account

Create the Hello World Contract

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

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:

• CONTRACT_PATH — path to your HelloWorld.sol file.

• PRIVATE_KEY — the private key from your account.

Example:

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

Transaction tracing enables a deeper look into smart contract inner calls and account creation calls. It is inspired by the OpenEthereum (Parity) node trace module, which is used in a lot of projects.

For now, the following JSON-RPC methods are implemented:

Currently, it is deployed on these endpoints for the Opera mainnet and testnet:

Start a New Go-Opera Tracing Node

Because of stored traces, a tracing node requires slightly bigger storage (around a quarter more). For more information, please follow the README.md file in the txtracing branch.

Building

Running

It's recommended to launch a new node from scratch with the CLI option --tracenode as this flag has to be set to use stored transaction traces.

Enable JSON-RPC API with the option trace:

A complete example command:

Genesis File

For the first start of the node, you have to specify the genesis file, which defines the blockchain and contains its history.

Import, Export, and delete

Transaction traces are created on the node while processing transactions and then stored in a node database. You can export these traces and import them on other nodes.

This addition allows for responses to certain changes that may alter the trace content without requiring a complete resynchronization of the blockchain.

Another method is to delete traces, which will be recreated upon the next request to them from the RPC API. However, this approach is not recommended because recreating traces this way is slower when the first request targets a non-existent transaction trace.

All these operations must be performed while the node is stopped, as they involve modifying data in the core database. For both export and delete operations, you can specify a block range to limit the number of processed transaction traces.

The command for exporting is export txtraces <filename.gz> <from block> <to block>:

For importing, it's:

No file needs to be specified when using the delete option. delete txtraces <from block> <to block>

Go-Opera Version Migration

This section provides information on migrating a transaction tracing API node to a newer version of go-opera. It will indicate whether a full node resynchronization is required due to stored transaction traces or if only a code update is necessary to upgrade from the previous version.

• release/txtracing/1.1.2-rc.2 — don't use this version

When using version 1.1.2, you need to add the db.preset argument for the starting Opera command. You can view the available options for this parameter with the opera help command. For standard conditions, please use the following option:

• db.preset=ldb-1

trace_block

Returns traces created at the given block.

Parameters

1. Quantity or Tag — Integer of a block number, or the string 'earliest', 'latest', or 'pending'.

Returns

• Array — Block traces.

Example

Request:

Response:

trace_transaction

Returns all traces of the given transaction.

Parameters

1. Hash — Transaction hash

Returns

• Array — Traces of given transaction

Example

Request:

trace_filter

Returns traces matching the given filter.

Parameters

1. Object — The filter object

   • fromBlock: Quantity or Tag — (optional) From this block.

   • toBlock: Quantity or Tag — (optional) To this block.

   • fromAddress: Array — (optional) Sent from these addresses.

   • toAddress: Address — (optional) Sent to these addresses.

   • after: Quantity — (optional) The offset trace number

   • count: Quantity — (optional) Integer number of traces to display in a batch.

Returns

• Array — Traces matching the given filter.

Example

Request:

trace_get

Returns trace at given position.

Parameters

1. Hash — Transaction hash.

2. Array — Index positions of the traces.

Returns

• Object — Trace object

Example

Request:

debug_traceBlockByNumber

The method returns a full stack trace of all invoked opcodes of all transaction that were included in a block identified by a block number. The parent of this block must be present or it will fail.

Parameters

1. Number - Block number to be traced.

2. Object - (optional) Options for the trace.

   • tracer: String - (optional) Setting this will enable JavaScript-based transaction tracing, described below.

Returns

• Array - A trace object per transaction inside the block.

Example

debug_traceBlockByHash

This method returns a full stack trace of all invoked opcodes of all transactions that were included in a block identified by a hash. The parent of this block must be present or it will fail.

Parameters

1. Hash — Hash of the block to be traced.

2. Object — (optional) Options for the trace.

   • tracer: String — (optional) Setting this will enable JavaScript-based transaction tracing, described below.

Returns

• Array — A trace object per transaction inside the block.

Example

debug_traceTransaction

This method will try to run the transaction in the same way it was executed on the network. It will replay any transactions that occurred before it in the block and then attempt to execute the transaction corresponding to the given hash.

Parameters

1. Hash — Hash of the transaction to be traced.

2. Object — (optional) Options for the trace.

   • tracer: String — (optional) Setting this will enable JavaScript-based transaction tracing, described below.

Returns

• Object — A trace object of the traced transaction.

Example

JavaScript-Based Tracer

Specifying the tracer option in the second argument of the debug tracing calls enables JavaScript-based tracing. In this mode, tracer is interpreted as a JavaScript expression that is expected to evaluate an object which must expose the result and fault methods. There exists 4 additional methods, namely: setup, step, enter, and exit. enter and exit must be present or omitted together.

Setup Method

Method setup is invoked once, in the beginning when the tracer is being constructed for each transaction being traced. It takes in one argument, config, which allows users to pass in options to the tracer. config is to be JSON-decoded for usage and its default value is "{}".

Step Method

Method step is a function that takes two arguments, log and db, and is called for each step of the EVM, or when an error occurs, as a transaction is traced.

log has the following fields:

• op: Object, an OpCode object representing the current opcode

• stack: Object, a structure representing the EVM execution stack

• memory: Object, a structure representing the contract’s memory space

• contract: Object, an object representing the account executing the current operation

And the following methods:

• getPC() — returns a number with the current program counter

• getGas() — returns a number with the amount of gas remaining

• getCost() — returns the cost of the opcode as a number

• getDepth() — returns the execution depth as a number

• getRefund() — returns the amount to be refunded as a number

• getError() — returns information about the error if one occurred, otherwise returns undefined

If an error is non-empty, all other fields should be ignored.

For efficiency, the same log object is reused on each execution step, updated with current values; make sure to copy values you want to preserve beyond the current call.

log.op has the following methods:

• isPush() — returns true if the opcode is a PUSHn

• toString() — returns the string representation of the opcode

• toNumber() — returns the opcode’s number

log.memory has the following methods:

• slice(start, stop) — returns the specified segment of memory as a byte slice

• getUint(offset) — returns the 32 bytes at the given offset

• length() — returns the memory size

log.stack has the following methods:

• peek(idx) — returns the idx-th element from the top of the stack (0 is the topmost element) as a big.Int

• length() — returns the number of elements in the stack

log.contract has the following methods:

• getCaller() — returns the address of the caller

• getAddress() — returns the address of the current contract

• getValue() — returns the amount of value sent from caller to contract as a big.Int

• getInput() — returns the input data passed to the contract

db has the following methods:

• getBalance(address) — returns a big.Int with the specified account’s balance

• getNonce(address) — returns a Number with the specified account’s nonce

• getCode(address) — returns a byte slice with the code for the specified account

• getState(address, hash) — returns the state value for the specified account and the specified hash

• exists(address) — returns true if the specified address exists

If the step function throws an exception or executes an illegal operation at any point, it will not be called on any further VM steps, and the error will be returned to the caller.

Result Method

Method result is a function that takes two arguments, ctx and db, and is expected to return a JSON-serializable value to return to the RPC caller.

ctx is the context in which the transaction is executed and has the following fields:

• type — String, one of the two values, CALL and CREATE

• from — Address, sender of the transaction

• to — Address, target of the transaction

• input — Buffer, input transaction data

• gas — Number, gas budget of the transaction

• gasUsed - Number, amount of gas used in executing the transaction (excludes txdata costs)

• gasPrice — Number, gas price configured in the transaction being executed

• intrinsicGas — Number, intrinsic gas for the transaction being executed

• value — big.Int, amount to be transferred in wei

• block — Number, block number

• output — Buffer, value returned from EVM

• time — String, execution runtime

Fault Method

Method fault is a function that takes two arguments, log and db, just like step, and is invoked when an error happens during the execution of an opcode which wasn’t reported in step. The method log.getError() has information about the error.

Ender and Exit Methods

Methods enter and exit are respectively invoked on stepping in and out of an internal call. More specifically, they are invoked on the CALL variants, CREATE variants, and also for the transfer implied by a SELFDESTRUCT.

enter takes a callFrame object as argument which has the following methods:

• getType() — returns a string which has the type of the call frame

• getFrom() — returns the address of the call frame sender

• getTo() — returns the address of the call frame target

• getInput() — returns the input as a buffer

• getGas() — returns a number that has the amount of gas provided for the frame

• getValue() — returns a big.Int with the amount to be transferred only if available, otherwise undefined

exit takes in a frameResult object which has the following methods:

• getGasUsed() — returns amount of gas used throughout the frame as a Number

• getOutput() — returns the output as a buffer

• getError() — returns an error if one occurred during execution and undefined otherwise

Introduction

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:

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

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:

Getting Started

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⁠

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.

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: