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.

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!

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

Mobile

1. Open your MetaMask app

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

3. Click Add Network

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

You can access the for some free testnet FTM.

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.

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 .

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.

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

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.

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.

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

How to Add FTM to Ledger

1. Open Ledger Live

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:

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

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.

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.

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

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 .

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.

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

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

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

• Swap tokens, powered by OpenOcean

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

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

Opera Mainnet

RPC

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

Create the Asset

1. Write the token smart contract:

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

Node Requirements

Minimum hardware requirements:

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

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.

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!

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 .

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

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.

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 .

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

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.

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.

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

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.

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

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:

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

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.

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

2. .

3. .

Install Foundry

Foundry is a development toolkit to work with smart contracts.

1. .

2. .

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 .

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.

• HTTPS_ENDPOINT — .

Example:

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

See the Chainstack documentation for more and .

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

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

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.

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:

Run a Read Node

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

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

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 .

Introduction

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

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:

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:

Create Contract

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

1. In your CLI run the following command:

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

USDC.e on 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 . It's the official, endorsed stablecoin of the Opera ecosystem.

Bridge USDC to Opera

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

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 Chainlink's documentation

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

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

When a user explores Opera through a , 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 .

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:

Storing wallets on managed servers is not recommended, and it is advised to 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

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

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.