Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Description of Bosagora's Proof of Stake (POS) consensus mechanism
Bosagora blockchain is using which is a combination of Casper the Friendly Finality Gadget (Casper-FFG) and the LMD-GHOST fork choice algorithm to achieve Proof of Stake (PoS) consensus. This is well battle tested and proven to be reliable and secure as it has been used for the Ethereum Beacon Chain consensus mechanism since December 2020.
Description of why to use BOSagora
BOSagora is a blockchain that uses a Proof of Stake consensus mechanism which means that it is very energy efficient. It uses a tiny fraction of the energy used by Proof of Work consensus blockchains which are very wasteful in energy consumption. For example, BitCoin requires more energy than some countries to keep it secure.
BOSagora has generous rewards given to those that keep it secure and also gives them voting rights in funds that can be used for projects to make a better World.
BOSagora is pursuing democracy, legitimacy, fairness, transparency and efficiency of the highest standards.
General information page about BOSagora
BOSagora is an open decentralized blockchain that is built using open source software from the public domain. The goal is to make a better world by using blockchain technology as a project enabler.
The word is defined in the wikipedia as originating from Ancient Greek to mean a public gathering space. This is an apt name for the Agora blockchain that is for public use and for the benefit of all.
High level description of the BOSagora Blockchain
The ultimate goal is for the BOSagora blockchain to be fully open and distributed to all using only PoS consensus. However, the first step to achieve this was to start with a Proof of Authority consensus mechanism which is also very energy efficient. This was to enable early adoption of the chain. The next step is to add a PoS consensus layer that runs alongside the PoA chain. In a similar way to how Ethereum had a PoW and PoS chain to enable the transition from PoW to only PoS. A A PoS consensus chain BOSagora runs with a PoA execution chain to prove secure and reliable, and the Agora Chain has been completely changed to a PoS consensus chain.
The initial stake required is 40,000 BOA per validator. Each validator will get a share of the allocated validator rewards if it behaves honestly by proposing blocks when required and attesting to valid blocks proposed by other validators. If a validator does not propose a block when it is the chosen validator or it does not attest to blocks within the expected time it will be penalized by having a small amount of stake removed. If it is proven to be dishonest then it will be slashed which results in larger amounts of stake being removed. Slashing only occurs for any of the following protocol violations: 1. a misbehaving block proposer who proposes two different blocks at the same slot height 2. an attester which publishes a vote with different source checkpoints for the same target checkpoint 3. an attester which publishes a vote that surrounds or is surrounded by another of its votes in relation to source and target checkpoints
Description of Chain information
BOSagora Mainnet
Network Name: BOSagora mainnet
New RPC URL: https://mainnet.bosagora.org
Chain ID: 2151
Currency Symbol: BOA
Agora Validator Deposit address: 0xC26Dd0f6e94afE288a2dd5D300F4dDaA0D93D9CB
BOSagora Testnet
Network Name: BOSagora testnet
New RPC URL: https://testnet.bosagora.org
Chain ID: 2019
Currency Symbol: BOA
Agora Validator Deposit address: 0xc11adf2BDF377dbABfB4344B7b8A18D552982680
Faucet: GET https://faucet.bosagora.org/request/boa/ + Your's BOA Address
Boascan (Execution layer explorer):
Agorascan (Consensus layer explorer):
Agora staking client:
Boascan (Execution layer explorer):
Agorascan (Consensus layer explorer):
Agora staking client:
Visit page to check what is required to become an Agora blockchain validator.
Blockchains rely on updates to enable new features and functionality without starting a new blockchain. For clients to be prepared for when the updates are available they need to install the client version which supports the update. Following sections describe the expected updates in the coming months.
This will be an upgrade that adds the ability to withdraw rewards and validators' staked deposits.
It is mandatory for node operators to upgrade before the applicable upgrade date.
The upgrade schedule is as follows
Mainnet Withdrawal Upgrade Date: August 23, 2023, 01:05:53 AM (UTC)
Mainnet Withdrawal Upgrade Epoch : 50,324
Your mainnet Agora node upgrade should be complete before this date.
Stop the existing node and run the command below.
Start the node.
The command below shows simple commands.
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Stop the existing node and run the command below.
Start the node.
The command below shows simple commands.
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
The monitoring dashboard data source has been updated.
Newly changed dashboard data source . The monitoring address and port are http://localhost:3000
After the Agora Withdrawal upgrade (August 23, 2023, 01:05:53 AM (UTC)), you will be able to withdraw your staked BOA on validator nodes in two ways:
In this how-to, you'll learn how to perform both types of withdrawals. Familiarity with Agora wallets, mnemonic phrases, and command lines is expected.
Your validator mnemonic: You'll use this to authorize your validator withdrawal request(s).
We'll install other dependencies as we go.
This section walks you through the process of performing a partial validator withdrawal, allowing you to withdraw staked balances above 40,000 BOA for each of your active Agora validators.
Retrieve your validator’s withdrawal_credentials from the deposit_data-XXX.json file that was generated when you first used the staking launchpad. The withdrawal_credentials value looks like this:
If you don't have the deposit_data-XXX.json file, you can retrieve your withdrawal_credentials by sending a request to your synced beacon node via Agora-cl API and providing your validator index or public key:
Your withdrawal credentials will be visible in the response to this request - look for withdrawal_credentials.
Example output with placeholder values:
If you already have a node running or installed using Agora-chain, you can skip the instructions below.
Linux / Mac
Windows
CAUTION
We recommend doing this next step without an Internet connection to be maximally secure. Either turn off the internet before introducing your mnemonic for signing or migrate to an air-gapped environment to continue the following steps.
Here’s the command to get started with the process. This command will not submit your signed message to the network yet, and will only generate the data needed for the next steps.
'folder' is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
By calling the command above, you should go through an interactive process that will ask you for the following information:
Your language. You can see the different options available, where English is one of the options, among others.
The network you wish to perform this operation for. example: mainnet,testnet or devnet.
Enter your mnemonic next
INFO
Inside the original deposit.json file used for staking you can count each validator's public key in sequential order starting from 0. The validator starting index is the index of the first validator key you would like to withdraw (i.e. validator key 1 has an index of 0, validator key 2 has an index of 1 etc.). For most stakers, the validator starting index should be set to 0 for withdrawing all their validator keys, however the validator starting index will be different if you choose to skip withdrawing some validators. There are other niche cases where the mnemonic is used for deposit generation multiple times, resulting in a different validator starting index. Validators spanning across different mnemonics will need to be counted separately with starting index as 0 on each of them.
INFO
Validator indices need to be provided sequentially without skipped indices in the order of original creation. You can typically find the order in your original deposit.json file. The generate-bls-to-execution-change command needs to be repeated in cases where multiple validator keys that are not in sequential order need to be withdrawn, and will require either merging of the output files or multiple blstoexecutionchange submissions. In the case of validators requiring different withdrawal addresses you will need to also repeat this process using the validator start index of the validator that the different withdrawal address.
Next you will be asked for your withdrawal credentials, which you should now have if you followed this guide
Next you will be asked for the BOA address you wish to use to receive your withdrawn funds. This needs to be checksummed, and you can get it from your wallet or a block explorer. You cannot change this once it is set on-chain, so triple check it before proceeding.
Below is an example of running through the interactive process explained above:
The above demonstrates two different validators withdrawing - one with validator index 838, the other with validator index 20303.
CAUTION
Make sure the validator_index corresponds to the correct chosen to_execution_address. Once this message is accepted on submission you will not be able to change it again!
Move the generated bls_to_execution_changes-*.json file to an online environment that has access to a synced beacon node for the next step.
This step requires access to a synchronized Agora-cl node.
You can use the ./agora.sh validator withdraw command, which will ask for terms of service acceptance and confirmation of command by providing additional flags, and also a path to the bls_to_execution_changes file from the previous step.
INFO
default Agora node REST <node-url> is http://localhost:3500 aka http://127.0.0.1:3500
Open a terminal in the location where you installed the agora-chain. Some users will need to give permissions to be executable. Linux users can do this by right clicking the file, going to permissions, and clicking the Allow executing file as program checkmark. This may be different for each operating system.
Linux / Mac
Windows
'folder' is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
This will extract data from the bls_to_execution_changes-*.json call the Beacon API endpoint on the synced Beacon Node and validate if the request was included.
On successful submission, the SignedBLStoExecutionChange messages are included in the pool waiting to be included in a block.
The withdrawal will be initiated by using the execution address you provided, and your validators’ withdrawal credentials will change to look something like this:
where the BOA address of your choosing will be found within.
You can track your withdrawal on an Agora Proof of Stake Block Scanner. Some examples listed below and will be based on network.
you can also confirm the withdrawal_credentials updated by querying your local Agora-cl node.
and you should see a response that contains withdrawal credentials that should have changed to the 0x01 format which includes your BOSagora execution address.
Once your withdrawal_credentials field on the validator is updated to the 0x01 prefix all withdrawal actions are complete. Withdrawals of earnings over 40,000 BOA will be automatically sent to the chosen BOSagora address when a block proposer includes your validator in its block. Note that a maximum of 16 validators can have their balances withdrawn per block so delay times may vary before seeing the values appear in the BOA address.
CAUTION
Instructions for setting your withdrawal address do not need to be repeated if withdrawal_credentials are updated to the 0x01 prefix.
Once the validator is both exited as well as having its withdrawal_credentials changed to the 0x01 prefix, the validator will automatically have its full balance withdrawn into the chosen Agora BOA address when a block proposer includes your validator in its block. Note that a maximum of 16 validators can have their balances withdrawn per block so delay times may vary before seeing the values appear in the BOA address.
CAUTION
Slashed or involuntarily exited validators will still need to go through the process of updating withdrawal_credentials to fully withdraw its remaining balance.
: This option lets you withdraw your earnings (that is, all value staked above 40,000 BOA) and continue validating.
: This option lets you liquidate your entire stake and earnings, effectively liquidating your validator node(s) and exiting the network.
Access to a beacon node: You'll need to connect your validator to a beacon node in order to submit your withdrawal request. Visit our for instructions if you need them.
The agora-chain installed: The is agora nodes and tool provided by the Agora research team.
Time to focus: This is a time-consuming procedure making a mistake can be expensive. Be vigilant against scammers; never share your mnemonic; take your time; ping us if you have any questions.
offline environment with your mnemonic to generate the blstoexecutionchange message(s)In this step, you submit a signed request to the Agora network using the tool provided by the BOSagora project.
installation instructions
Now that the Agora-chain's tool is executable, you can then use it to generate your signed request. You need to use your mnemonic for this step, so doing it offline is key and ensuring you do not paste your mnemonic anywhere else than necessary.
Next, you will be asked for the starting index you used to create your validators (read more about hd wallets ). For most users, this will be 0 unless you created validators from a non default index.
You will then be asked the validator indices for the validators you wish to generate the message for. You can find your validator indices on block explorers such as or in your Agora-cl validator client logs. For example, the validator with public key 0x800b1496d4532bbf3404de63619b779bad95dba69396e5d5c4eb64c7aa4a9a1a77229ec8783ad114a14d2eda2a3483ca on has validator index 20, which you can verify by navigating to its .
blstoexecutionchange message(s) that the corresponding validator will set to the chosen BOA addressOnce you complete the above, you’ll have a file contained in the bls_to_execution_changes/ folder of your . It will represent a list of BLS to execution messages that have been signed with your private keys and are ready to submit to Agora. Here’s what a sample file of these looks like. Example output with placeholder values:
: ,
withdrawal_credentials are updated is automatic, but will take time.Please follow our .
Refer to the above option 1: guidance to change your validator's withdrawal credentials.
withdrawal_credentials are updated and the validator is fully exited is automatic, but will take time.Setting up an Agora node
It is a good idea to first run a test node within the Agora testnet to get familiar with how things work before running a node in the Agora mainnet
This will be an upgrade that adds the ability to withdraw rewards and validators' staked deposits.
The timing of the upgrade will be applied first on Agora Testnet, then we will watch for network stabilization and upgrade to Agora Mainnet.
The upgrade schedule is as follows.
TestNet Withdrawal Upgrade Date: July 12, 2023, 10:04 AM
Testnet withdrawal upgrade Epoch: 58857
The testnet agora node upgrade must be completed before that date and time.
Stop the existing node and run the command below.
Start the node.
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Stop the existing node and run the command below.
Start the node.
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
The monitoring dashboard data source has been updated.
Withdraw rewards and how to withdraw deposits can be found .
For more information about upgrading and running nodes, see .
Withdraw rewards and how to withdraw deposits can be found .
For more information about upgrading and running nodes, see .
Newly changed dashboard data source . The monitoring address and port are http://localhost:3000
Any member of congress can vote by following these steps:
Find the proposal you want to vote for and click on it to enter the proposal details screen.
Review the proposal details and discussions and decide whether to support, oppose, or abstain from the proposal.
Select "Vote" tab to enter the voting screen.
Select one of the three buttons: "Yes", "No", and "Abstain".
Click the "Vote" button.
When the voting process is complete, a completion message is displayed.
Any member of congress can begin the decision-making process by writing a business proposal.
Proposal authors must provide the following information so that other members of the congress can understand and participate:
Type of proposal
Title of proposal
Voting period
Request amount
Business goals and descriptions
Related attachments
In order to prevent abuse, a small fee must be paid according to the policy when registering a proposal, and the fee to be paid is automatically calculated and presented according to the entered request amount.
Members of the congress can participate in the proposed business proposal in three ways: Discussion, Evaluation and Voting.
In discussion, members of congress can share opinions on proposals, recommend good proposals, and display them sorted by the latest and number of recommendations.
Members of congress can comment on registered opinions, and registered opinion and comments can not be modified or deleted.
In evaluating, the suitability of the proposal is evaluated to determine whether to accept it as a formal proposal. Evaluation will be conducted for 7 days including the date of registration of the proposal.
In voting, members of congress can vote for, against, or abstain from proposals that have passed evaluation.
Voting is done to reach consensus.
Voting information is recorded in blocks for transparency.
The hash of the voting information is recorded so that the voting information is not disclosed until the end of the voting.
After voting ends, voting information is recorded in a block, and voting information is aggregated and verified using the hash already recorded.
A quorum for decision-making is one-third of all members of the congress.
A proposal is approved if the percentage of votes in favor exceeds the percentage of votes against by 10%.
Funds can be withdrawn 24 hours after the closing time for voting.
Funds can not be withdrawn if the foundation vetoes it.
Three deploy methods are described in this section.
Any member of congress can begin the decision-making process by writing a system proposal.
Proposal authors must provide the following information so that other members of the congress can understand and participate:
Type of proposal
Title of proposal
Voting period
Goals and descriptions
Related attachments
In order to prevent abuse, a small fee must be paid according to the policy when registering the proposal, and the fee to be paid is calculated and presented automatically.
Members of congress can participate in the proposed system proposal in two ways: Discussion and Voting.
In Discussion, members of congress can share opinions on proposals, recommend good proposals, and display them sorted by the latest and number of recommendations.
Members of congress can comment on registered opinions, and registered opinions and comments cannot be modified or deleted.
In voting, members of congress can vote for, against, or abstain from system proposals.
Voting is done to reach consensus.
Voting information is recorded in blocks for transparency.
The hash of the voting information is recorded so that the voting information is not disclosed until the end of the voting.
After voting ends, voting information is recorded in a block, and voting information is aggregated and verified using the hash already recorded.
A quorum for decision-making is one-third of all members of the congress.
A proposal is approved if the percentage of votes in favor exceeds the percentage of votes against by 10%.
If the proposal is approved, the development team proceeds with the development according to the proposal.
How to install a node for the Agora Testnet
Available commands and descriptions of agora.sh
Init execution node
Run execution node
Run consensus node
This step is optional but essential if you want to participate in securing the Agora Blockchain, have the right to vote, and receive rewards.
Create personal keys and prepare deposit data and deposit stake
Generate your validator keys when you don't have mnemonic
Generate your validator keys when you have mnemonic
Import your key stores
or
<your key stores folder> is where the validator keys are stored. The default folder is ./validator_keys
List your key stores in your wallet
Backup your key stores in your wallet
<folder> is where the backup key is stored. The default folder is ./backup-wallet
Run validator
Voluntary exit of the validator
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
export
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
import
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
Stop docker-compose
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
or
Stop docker-compose
or
Available commands and descriptions of agora.bat
Init execution node
Run execution node
Run consensus node
This step is optional but essential if you want to participate in securing the Agora Blockchain, have the right to vote, and receive rewards.
Create personal keys and prepare deposit data and deposit stake
Generate your validator keys when you don't have mnemonic
Generate your validator keys when you have mnemonic
Import your key stores
or
<your key stores folder> is where the validator keys are stored. The default folder is ./validator_keys
List your key stores in your wallet
Backup your key stores in your wallet
<folder> is where the backup key is stored. The default folder is ./backup-wallet
Run validator
Voluntary exit of the validator
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
export
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
import
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
Stop docker-compose
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
or
Stop docker-compose
or
How to install a node for the Agora Mainnet
Available commands and descriptions of agora.sh
Init execution node
Run execution node
Run consensus node
Generate your validator keys when you don't have mnemonic
Generate your validator keys when you have mnemonic
Import your key stores
or
<your key stores folder> is where the validator keys are stored. The default folder is ./validator_keys
List your key stores in your wallet
Backup your key stores in your wallet
<folder> is where the backup key is stored. The default folder is ./backup-wallet
Run validator
Voluntary exit of the validator
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
export
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
import
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
Stop docker-compose
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
or
Stop docker-compose
or
Available commands and descriptions of agora.bat
Init execution node
Run execution node
Run consensus node
Generate your validator keys when you don't have mnemonic
Generate your validator keys when you have mnemonic
Import your key stores
or
<your key stores folder> is where the validator keys are stored. The default folder is ./validator_keys
List your key stores in your wallet
Backup your key stores in your wallet
<folder> is where the backup key is stored. The default folder is ./backup-wallet
Run validator
Voluntary exit of the validator
Generate the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
Send the SignedBLSToExecutionChange data to enable withdrawals
<folder> is where the SignedBLSToExecutionChange data is stored. The default folder is ./bls_to_execution_changes
export
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
import
<folder> is where the slashing protection history data is stored. The default folder is ./slashing-protection-export
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
Stop docker-compose
Init the execution node
Import your key stores
or
Edit wallet password
Edit transaction fee receiving address
Run docker-compose
or
Stop docker-compose
or
Hardhat is a development environment to compile, deploy, test, and debug your smart contract.
There are a few technical requirements before we start. Please install the following: Requirements:
There are a few technical requirements before we start. Please install the following: Requirements:
Windows, Linux, or Mac OS X
First, you need to create an empty project npm init --yes
Once your project is ready, you should run
It's recommended to install some dependencies.
To use your local installation of Hardhat, you need to use npx to run it (i.e. npx hardhat).
To create your Hardhat project run npx hardhat in your project folder:
Initialize your project:
Once this project is initialized, you'll now have a project structure with the following items:
contracts/: Directory for Solidity contracts
scripts/: Directory for scriptable deployment files
test/: Directory for test files for testing your application and contracts
hardhat-config.js: Hardhat configuration file
Go to hardhat.config.js
Update the config
Note
It requires a mnemonic to be passed in for Provider, this is the seed phrase for the account you'd like to deploy from. Create a new .secret file in the root directory and enter your 12-word mnemonic seed phrase to get started. To get the seed words from metamask wallet you can go to Metamask Settings, then from the menu choose Security and Privacy where you will see a button that says reveal seed words.
To compile a Hardhat project, change to the root of the directory where the project is located and then type the following into a terminal:
Run this command at root of the project directory:
Remember your address, transaction_hash and other details provided would differ, Above is just to provide an idea of structure.
Congratulations! You have successfully deployed ERC20 Smart Contract. Now you can interact with the Smart Contract.
Deploys a ERC20 smart contract with a message, and renders it in the front-end. You can interact with the smart contract easily!
Remix is an online IDE to develop smart contracts.
You need to choose Solidity Compiler and Deploy and Run Transactions.
Go to File Explorers, And Create a new file, Name it ERC20Token.sol
Copy/Paste the Smart contract below into the newly created file ERC20Token.sol
Modify "TOKEN_NAME", "TOKEN_SYMBOL", "DECIMALS" and "TOTAL_SUPPLY" according to your requirements.
Step1: Click the button to switch to compile page
Step2: Select the "ERC20Token" contract
Step3: Enable "Auto compile" and "optimization"
Step4: Click "ABI" to copy contract ABI and save it.
Now, We have to deploy our smart contract on BizNet Network. For that, we have to connect to web3 world, We will be using Metamask.
Copy your address from Metamask
Now, let's Deploy the Smart Contract on Testnet
Select "Injected Web3" in the ENVIRONMENT dropdown and your contract
Metamask accepts the Connection Request!
From the CONTRACT dropdown menu, select the ERC20Token.sol you created earlier.
Click the Deploy button in Remix and accept another Metamask popup that requires transaction confirmation once connected!
To run an Agora node, you must first have Docker installed and running. See for instructions on how to install the Docker Engine
See for instructions on how to install
If you want to test transfers then tBOA can be obtained from the Testnet Faucet at <Your testnet account>
However, in this section we are using the Agora Testnet BOA so rewards have no real value. Do not use real BOA in Testnet but request 40,000 tBOA by sending an email to with subject "validator" or if this fails then make a request in Telegram at .
Go to website
If you want to test transfers then tBOA can be obtained from the Testnet Faucet at <Your testnet account>
However, in this section we are using the Agora Testnet BOA so rewards have no real value. Do not use real BOA in Testnet but request 40,000 tBOA by sending an email to with subject "validator" or if this fails then make a request in Telegram at .
Go to website
Go to website
To run an Agora node, you must first have Docker installed and running. See for instructions on how to install the Docker Engine
See for instructions on how to install
Go to website
Go to website
You can write your own smart contract or download the .
You can check the deployment status here: or
This dApp implements a "Hello World" style application that echoes a message passed to the contract to the front end. This tutorial is intended to be followed using the online IDE available at .
Create a new contract ERC20Token.sol and copy the contract code from the ERC20 token template
In the first line, pragma solidity ^0.8.0 specifies that the source code is for a Solidity version greater than 0.8.0. are common instructions for compilers about how to treat the source code (e.g., pragma once).
A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain. Learn more about the and in the docs.
Head over to Faucet - and request test BOA
Congratulations! You have successfully deployed an ERC20 Contract. Now you can interact with the Smart Contract. Check the deployment status here:
VOTERA is an online decision-making tool that overcomes the challenges of group decision-making and enables more comprehensive and efficient decision-making.
By storing decision data in blocks, VOTERA ensures transparency and makes accountability clear.
To maintain confidentiality, a hash of voting data is stored in blocks for data validation during the voting period.
At the end of the voting period, the voting data is written to the block and the data is verified through the recorded hash.
Information on discussion and evaluation is stored on a separate server and is provided so that participants can view it at any time.
A crypto wallet is a device or program used for the transfer and storage of cryptocurrency. Crypto wallets can be of different types, such as paper wallets, hardware wallets, and software wallets. There are also several smartphone mobile apps and computer programs that provide a user-friendly way to create and manage wallets. Along with cryptocurrency, crypto wallets store a collection of crypto keys that are used for sending, receiving, and tracking ownership of cryptocurrencies.
A key pair is a cryptographically-derived securely generated private and public key. A private key and its corresponding public key are together known as a key pair. A wallet contains a collection of one or more key pairs and provides some means to interact with them. The security of any crypto wallet depends upon how the private key is stored.
The public key is known as the wallet's receiving address or simply its address. The wallet address may be shared and displayed freely. When another party is going to send some amount of cryptocurrency to a wallet, they need to know the wallet's receiving address. Depending on a blockchain's implementation, the address can also be used to view certain information about a wallet, such as viewing the balance, but has no ability to change anything about the wallet or withdraw any tokens.
In order to send cryptocurrencies to another address or to make any changes to the wallet, the private key is used for digitally signing the transactions. It is important to note that the private key must never be shared and should always be kept securely. If by any means access is gained to the private key attached to a wallet, the attacker can withdraw all the tokens contained. Furthermore, if the private key for a wallet is lost, any tokens that have been sent to or stored in that wallet's address are permanently lost.
List of Wallets Supporting Agora
This article is a guide about key management strategy on the client side of your Decentralised Application on Agora
web3.js is a javascript library that allows our client-side application to talk to the blockchain. We configure web3 to communicate via Metamask.
If the installation and instantiation of web3 were successful, the following should successfully return a random account:
If you have a backup private key to your account, you can use it to restore your account.
To facilitate a marketplace on BizNet to pull in off-chain metadata for ERC721 assets, the NFT contract will need to return a URI where the metadata can be found. To find this URI, the token URI method in ERC721 and the URI method in ERC1155 are used to track your NFT. You should implement the function in the Contract:
The token URI function in your Contract should return an HTTP or IPFS URL. When queried, this URL should in turn return a JSON blob of data with the metadata for your token.
Here's how each of these properties works:
name
Name of the item. Max 200 characters.
description
A human-readable description of the item. Markdown is supported. Max 500 characters.
image
This is the URL to the image of the item. It can be just about any type of image. A 350 x 350 image is recommended.
animation_url
This is the URL to a multi-media attachment for the item. The file extensions GLTF, GLB, WEBM, MP4, M4V, OGV, and OGG are supported, along with the audio-only extensions MP3, WAV, and OGA.
animation_type
This is the file format of the multi-media attachment provided from animation_url.
external_url
This is the URL that will appear below the asset's image on the marketplace and will allow users to leave the marketplace and view the item on your site.
attributes
These are the attributes for the item to describe the detail of the NFT. (see array below)
To present NFT traits, include the following array in the metadata:
Here trait_type is the name of the trait, value is the value of the trait, and display_type is a field indicating how you would like a numeric value should be displayed. For string traits, you don't have to worry about display_type. All traits included in the attributes will be displayed in Attribute. If you don't want to have a trait_type for a particular trait, you can include just a value in the trait and it will be set as a generic attribute.
Numeric Traits
There are 3 supported options for display_type: number will show the value in pure number, boost_number allows you to show the number with a Plus or Minus symbol, and boost_percentage is similar to boost_number but will show a percent sign behind the number.
Date
The marketplace also supports date traits in date display_type. Pass in a UNIX timestamp as the value.
Output:
Output:
The balance will be bumped by e18 for BOA.
Parameters
Object - The transaction object to send:
from - String|Number: The address for the sending account. Uses the web3.eth.defaultAccount property, if not specified. Or an address or index of a local wallet in web3.eth.accounts.wallet.
to - String: (optional) The destination address of the message, left undefined for a contract-creation transaction.
value - Number|String|BN|BigNumber: (optional) The value transferred for the transaction in wei, also the endowment if it’s a contract-creation transaction.
gas - Number: (optional, default: To-Be-Determined) The amount of gas to use for the transaction (unused gas is refunded).
gasPrice - Number|String|BN|BigNumber: (optional) The price of gas for this transaction in wei, defaults to web3.eth.gasPrice.
data - String: (optional) Either a ABI byte string containing the data of the function call on a contract, or in the case of a contract-creation transaction the initialization code.
nonce - Number: (optional) Integer of a nonce. This allows overwriting your own pending transactions that use the same nonce.
In this tutorial, we will create a non-fungible token (NFT) and deploy it to a public testnet.
We begin by creating a new project.
We will set up our Solidity project using truffle init to create a contracts directory and configuration to connect to a network.
The Preset contracts have already been compiled, so we only need to copy the artifacts to the build/contracts directory.
Using your favorite editor create 2_deploy.js in the migrations directory with the following contents:
We can deploy our new NFT to our development blockchain using migrate.
We can then use our deployed contract.
The accounts that we can use were displayed when we started truffle develop
We can call the contract to read token metadata such as name, symbol and baseURI
We can send a transaction to mint tokens to a given account, from an account with the minter role. In our case we are minting from the account which deployed the token, which is given the minter role.
We will mint 1 NFT with token ID 0.
We can check the owner of the token and the token URI for the metadata
How you create and host this metadata is up to you. I would suggest using a domain that you control to point to where you host the data so that you can move it as required.
Warning For production we need to store our metadata in a permanent location that can exist for the life of the token.
Next we will deploy to Agora testnet .
You will need the following:
RPC URL of TestNet
@truffle/hdwallet-provider installed
Configure truffle-config.js for TestNet
A funded testnet account and mnemonic
A secrets.json or another secret-management solution. Make sure you don’t commit this to GitHub!
My truffle-config.js has the following
We can send a transaction to mint tokens to a given account, from an account with the minter role.
In our case we are minting from the account which deployed the token, which is given the minter role.
To see configured accounts run the command accounts.
We will mint 1 NFT with token ID 1. Specify the address that you want to be the token holder (0xc7e4bBc4269fdC62F879834E363173aeE7895F45 is one of my test accounts)
There are a few technical requirements before we start. Please install the following: Requirements:
Windows, Linux, or Mac OS X
Recommendations for Windows
If you're running Truffle on Windows, you may encounter some naming conflicts that could prevent Truffle from executing properly. Please see the section on resolving naming conflicts for solutions.
Once we have those installed, we only need one command to install Truffle:
To verify that Truffle is installed properly, type truffle version on a terminal. If you see an error, make sure that your npm modules are added to your path.
The first step is to create a Truffle project. We'll use the *MegaCoin as an example, which creates a token that can be transferred between accounts:
To initialize your project use the following command
Once this operation is completed, you'll now have a project structure with the following items:
contracts/: Directory for Solidity contracts
migrations/: Directory for scriptable deployment files
test/: Directory for test files for testing your application and contracts
truffle-config.js: Truffle configuration file
You can write your own smart contract or download the ERC20 token smart contract template.
To compile a Truffle project, change to the root of the directory where the project is located and then type the following into a terminal:
Go to truffle-config.js
Update the truffle-config
Notice, it requires a mnemonic to be passed in for Provider, this is the seed phrase for the account you'd like to deploy from. Create a new .secret file in the root directory and enter your 12-word mnemonic seed phrase to get started. To get the seed words from Metamask wallet you can go to Metamask Settings, then from the menu choose Security and Privacy where you will see a button that says reveal seed words.
Run this command the root of the project directory:
A contract will be deployed on Agora(BizNet) Testnet, it looks like this:
Remember your address, transaction_hash and other details provided would differ, Above is just to provide an idea of structure.
Congratulations! You have successfully deployed ERC20 Smart Contract. Now you can interact with the Smart Contract.
Block explorers are your portal to Agora's data. You can use them to see real-time data on blocks, transactions, validators, accounts, and other on-chain activity.
BOSagora is transparent by design so everything is verifiable. Block explorers provide an interface for getting this information. And this is for both the main BOSagora network and the testnets, should you need that data. Data is divided into execution data and consensus data. The execution data refers to the transactions that have been executed in a specific block. The consensus data refers to the blocks themselves and the validators who proposed them.
Here's a summary of the types of data you can get from a block explorer.
New blocks are added to BOSagora every 12 seconds (unless a block proposer misses its turn), so a near-constant stream of data gets added to block explorers. Blocks contain a lot of important data that you may find useful:
Standard data
Block height - The block number and length of the blockchain (in blocks) on creation of the current block
Timestamp - The time at which a block was proposed
Transactions - The number of transactions included within the block
Fee recipient - The address that received gas fee tips from transactions
Block Reward - The amount of BOA awarded to the validator who proposed the block
Size - The size of the data within the block (measured in bytes)
Gas used - The total units of gas used by the transactions in the block
Gas limit - The total gas limits set by the transactions in the block
Base fee per gas - The minimum multiplier required for a transaction to be included in a block
Burnt fees - How much BOA is burned in the block
Extra data - Any extra data the miner has included in the block
Advanced data
Hash - The cryptographic hash that represents the block header (the unique identifier of the block)
Parent hash - The hash of the block that came before the current block
StateRoot - The root hash of Merkle trie which stores the entire state of the system
Not only will block explorers give you data about Gas usage in transactions and blocks, but some will give you information on the network's current gas prices. This will help you understand network usage, submit safe transactions and not overspend on gas. Look out for APIs that can help you get this information into your product's interface. Gas-specific data covers:
Estimated units of gas needed for a safe but slow transaction (+ estimated price and duration)
Estimated units of gas needed for an average transaction (+ estimated price and duration)
Estimated units of gas needed for a fast transaction (+ estimated price and duration)
Average confirmation time based on gas price
Contracts that are consuming gas - in other words, popular products that are seeing lots of usage on the network
Accounts that are spending gas - in other words, frequent network users
Block explorers have become a common place for people to track the progress of their transactions. That's because the level of detail you can get provides extra certainty. Transaction data includes:
Standard data
Transaction hash - A hash generated when the transaction is submitted
Status - An indication of whether the transaction is pending, failed or a success
Block - The block in which the transaction has been included
Timestamp - The time at which a miner mined the transaction
From - The address of the account that submitted the transaction
To - The address of the recipient or smart contract that the transaction interacts with
Tokens transferred - A list of tokens that were transferred as part of the transaction
Value - The total BOA value being transferred
Transaction fee - The amount paid to the miner to process the transaction (calculated by gas price*gas used)
Advanced data
Gas limit - The maximum number of gas units this transaction can consume
Gas used - The actual amount of gas units the transaction consumed
Gas price - The price set per gas unit
Nonce - The transaction number for the from address (bear in mind this starts at 0 so a nonce of 100 would actually be the 101st transaction submitted by this account
Input data - Any extra information required by the transaction
There's a lot of data that you can access about an account. This is why it's often recommended to use multiple accounts so that your assets and value can't be easily tracked. There are also some solutions being developed to make transactions and account activity more private. But here's the data that's available for accounts:
User accounts
Account address - The public address you can use to send funds to
BOA balance - The amount of BOA associated with that account
Total BOA value - The value of the BOA
Tokens - The tokens associated with the account and their value
Transaction history - A list of all the transactions where this account was either the sender or the recipient
Smart contracts
Smart contract accounts have all the data that a user account will have, but some block explorers will even display some code information too. Examples include:
Contract creator - The address that deployed the contract to Mainnet
Creation transaction - The transaction that included the deployment to Mainnet
Source code - The solidity or vyper code of the smart contract
Contract ABI - The Application Binary Interface of the contract—the calls the contract makes and the data received
Contract creation code - The compiled bytecode of the smart contract is created when you compile a smart contract written in Solidity or Vyper, etc.
Contract events - A history of the methods called in the smart contract—basically a way to see how the contract is being used and how often
Tokens are a type of contract so they'll have similar data to a smart contract. But because they have value and can be traded they have additional data points:
Type - Whether they're an ERC-20, ERC-721, or another token standard
Price - If they're an ERC-20 they'll have a current market value
Market cap - If they're an ERC-20 they'll have a market cap (calculated by price*total supply)
Total supply - The number of tokens in circulation
Holders - The number of addresses that hold the token
Transfers - The number of times the token has been transferred between accounts
Transaction history - A history of all the transactions including the token
Contract address - The address of the token that was deployed to Mainnet
Decimals - ERC-20 tokens are divisible and have decimal places
Some block data is concerned about the health of Agora more holistically.
Total transactions - The number of transactions since Agora chain was created
Transactions per second - The number of transactions processable within a second
BOA price - The current valuations of 1 BOA
Total BOA supply - Number of BOA in circulation—remember new BOA is created with the creation of every block in the form of block rewards
Market cap - Calculation of price*supply
For security reasons, randomized committees of validators are created at the end of every epoch (every 6.4 minutes). Epoch data includes:
Epoch number
Finalized status - Whether the epoch has been finalized (Yes/No)
Time - The time the epoch ended
Attestations - The number of attestations in the epoch (votes for blocks within slots)
Deposits - The number of BOA deposits included in the epoch (validators must stake BOA to become validators)
Slashings - Number of penalties given to proposers of blocks or attestors
Voting participation - The amount of staked BOA used to attest blocks
Validators - Number of validators active for the epoch
Average Validator balance - Average balance for active validators
Slots - Number of slots included in the epoch (slots include one valid block)
Slots are opportunities for block creation, the data available for each slot includes:
Epoch - The epoch in which the slot is valid
Slot number
Status - The status of the slot (Proposed/Missed)
Time - The slot timestamp
Proposer - The validator that proposed the block for the slot
Block root - The hash-tree-root of the Agora Block
Parent root - The hash of the block that came before
State root - The hash-tree-root of the Agora State
Signature
Randao reveal
Graffiti - A block proposer can include 32 byte long message to its block proposal
Execution Data
Block hash
Deposit count
Deposit root
Attestations - Number of attestations for the block in this slot
Deposits - The number of deposits during this slot
Voluntary exits - The number of validators that left during the slot
Slashings - Number of penalties given to proposers of blocks or attestors
Votes - The validators that voted for the block in this slot
Proof-of-stake divides time into slots and epochs. So that means new data!
Proposer - The validator that was algorithmically chosen to propose the new block
Epoch - The epoch in which the block was proposed
Slot - The slot in which the block was proposed
Attestations - The number of attestations included in the slot—attestations are like votes that indicate the block is ready to go to the Agora Chain
Validators are responsible for proposing blocks and attesting to them within slots.
Validator number - Unique number that represents the validator
Current balance - The validator's balance including rewards
Effective balance - The validator's balance that is used for staking
Income - The rewards or penalties received by the validator
Status - Whether the validator is currently online and active or not
Attestation effectiveness - The average time it takes for the validator's attestations to be included in the chain
Eligibility for activation - Date (and epoch) when the validator became available to validate
Active since - Date (and epoch) when the validator became active
Proposed blocks - The block that the validator has proposed
Attestations - The attestations that the validator has provided
Deposits - The from address, transaction hash, block number, timestamp, amount and status of the staking deposit made by the validator
Attestations are "yes" votes to include blocks in the chain. Their data relates to a record of the attestation and the validators who attested
Slot - The slot in which the attestation took place
Committee index - The index of the committee at the given slot
Aggregation bits - Represents the aggregated attestation of all participating validators in the attestation
Validators - The validators that provided attestations
Agora block root - Points to the block to which validators are attesting
Source - Points to the latest justified epoch
Target - Points to the latest epoch boundary
Signature
The consensus layer top-level data includes the following:
Current epoch
Current slot
Active validators - Number of active validators
Pending validators - Number of validators waiting to be made active
Staked BOA - Amount of BOA staked in the network
Average balance - Average BOA balance of validators Thank you @wackerow for writing this document.
A decentralized application (dapp) is an application built on a decentralized network that combines a smart contract and a frontend user interface. On Ethereum, smart contracts are accessible and transparent so your dapp can even include a smart contract that someone else has written.
A dapp has its backend code running on a decentralized peer-to-peer network. Contrast this with an app where the backend code is running on centralized servers.
Decentralized - dapps operate on Ethereum, an open public decentralized platform where no one person or group has control
Deterministic - dapps perform the same function irrespective of the environment in which they get executed
Turing complete - dapps can perform any action given the required resources
Isolated - dapps are executed in a virtual environment known as Ethereum Virtual Machine so that if the smart contract has a bug, it won’t hamper the normal functioning of the blockchain network
Dapps have their backend code (smart contracts) running on a decentralized network and not a centralized server. They use the Agora blockchain for data storage and smart contracts for their app logic.
A smart contract is like a set of rules that live on-chain for all to see and run exactly according to those rules. Imagine a vending machine: if you supply it with enough funds and the right selection, you'll get the item you want. And like vending machines, smart contracts can hold funds much like your BOA account. This allows code to mediate agreements and transactions.
Once dapps are deployed on the Agora network you can't change them. Dapps can be decentralized because they are controlled by the logic written into the contract, not by an individual or a company.
To try a dapp, you'll need a wallet and some BOA. A wallet will allow you to connect, or log in. And you'll need BOA to pay any transaction fees.
Get some BOA Dapp actions cost a transaction fee
Ready? Choose a dapp to try out
The MetaMask (Wallet) must be installed and connected before using the Bridge. Since the bridge supports bidirectional transmission, It will first explain the scenario of transferring from Ethereum Mainnet ERC-20 BOA to BOSAGORA Agora(BizNet) BOA.
Select the departure network first. In this case, select Ethereum Mainnet.
The requirement is a small amount of gas ratio ETH and ERC-20 BOA to be transmitted to Ethereum Mainnet.
The bridge requires between 3 and 10 minutes to run. Do not close the browser while running the Bridge.
From Confirm that network Ethreum Mainnet is selected, balance the ERC20 BOA, and enter the amount of BOA to be sent to Agora(BizNet) network. The maximum input amount must be entered as much as the holding amount before transmission.
** Transfer amount - (Fee + Gas Tokens for use) = Amount received **
Please note that the exchange rate is 1 BOA = 1 BOA, but the fee will be deducted to measure the amount received by the arrival network because the Atomic swap algorithm generates gas costs in each network.
Click Approve BOA to approve. This is to approve the withdrawal from the smart contract.
Click the "OK" button on the "METAMASK" for Approve.
In BOASwap, when a transaction is confirmed, an Approved BOA message is displayed in the upper right corner.
Click the "Transfer" button to transfer the BOA to the arrival network using the Bridge.
Check the amount to be sent and the amount to be delivered, check the fee, and click the "Confirm Bridge" button.
Click the "OK" button on the "METAMASK" to execute the Bridge Contract.
"Transaction Submitted" Check the pop-up and wait for 3 to 10 minutes in the Pending state.
** Please do not move the browser address during the Pending state and wait. **
** BOASwap needs to generate and submit a secret key, check the Bridge relay node, and run the Bridge protocol. **
If the Close button is visible, this process is complete. Click the "Close" button.
Go to the MyAssets menu and change to Agora(BizNet) network. Check if your BOSAGORA BOA has been deposited well.
Bridge links them between Ethereum MainNet and Agora(BizNet)'s respective blockchains and mediates transactions. Currently, BOA tokens are supported for coin transfer from Ethereum MainNet to Agora(BizNet), and this transaction is possible for two-way transactions (two-way pegging). Performs a complete exchange with an atomic swap algorithm.
Ethereum MainNet ERC20 BOA and Agora(BizNet) BOA exchange rates are 1BOA = 1BOA. In each network, the issuance is pegging and unpegging, and the total coin issuance is fixed.
Bridge Process Flow Chart
If you want to be able to receive BOA and other supported tokens on the BizNet blockchain, you will first need to create a wallet and configure .
1
web3.js doc is
Marketplaces on BizNet support metadata that is structured according to . Additionally, several properties for your items are supported, giving you all the sorting and filtering capabilities on BizNet Marketplaces. The below metadata structure, allows the BizNet Marketplace to read and display the details about the assets which your NFTs represent.
An ERC20 token must implement the interface IERC20 in . This is a template contract . Users just need to fill in _name, _symbol, _decimals and _totalSupply according to their own requirements:
Then users can use and to compile and deploy the ERC20 contract to BizNet.
This work is inspired by
ERC721 is a standard for representing ownership of , that is, where each token is unique such as in real estate or collectibles.
We will use contracts in to create an ERC721 and deploy using Truffle.
Then we install which has an implementation of ERC721.
Next, we install a development tool for deployment, for this tutorial we will use but we could use any other tools such as Builder, Remix, or .
We are going to use Preset which is an ERC721 that is preset so it can be minted (with auto token ID and metadata URI), paused, and burned.
We will use to open a Truffle console with a development blockchain
Head over to and request test BOA
includes an optional metadata extension with a name, symbol and for each tokenID a tokenURI with can point to a JSON file with name, description and image for the given token ID.
For this tutorial, we will use where we can store a single JSON file in a GitHub repository that we can access via a fake JSON server.
A sample JSON for tokenID 1 is:
To deploy, we will use the instructions for
You can check the deployment status here: or
: Agora execution layer chain explorer
: Agora consensus layer chain explorer
A dapp can have frontend code and user interfaces written in any language (just like an app) to make calls to its backend. Furthermore, its frontend can get hosted on decentralized storage such as .
Set up a wallet A wallet is your "login" for a dapp
Connect to using a Chrome browser.
URL: Contract address:
In order for a web app to interact with the Agora blockchain (i.e. read blockchain data and/or send transactions to the network), it must connect to an Agora node.
If you want to use JavaScript to connect with an Agora node, it's possible to use vanilla JavaScript but several convenience libraries exist within the ecosystem that makes this much easier. With these libraries, developers can write intuitive, one-line methods to initialize JSON RPC requests (under the hood) that interact with Agora.
The following Ethereum documents are relevant to Agora as the JSON-RPC specification is the same.
Ethers.js - Complete Ethereum wallet implementation and utilities in JavaScript and TypeScript
Web3-wrapper - Typescript alternative to Web3.js
Alchemyweb3 - Wrapper around Web3.js with automatic retries and enhanced apis
Alchemy NFT API - API for fetching NFT data, including ownership, metadata attributes and more
The areas provided by BOASwap can be divided into My Assets, Swap, Pool, and Bridge.
Agora: It is a reliable BOASAGORA blockchain network composed of multiple nodes that achieve consensus with the POS consensus algorithm. Smart contracts can be executed with Agora’s Ethereum Virtual Machine (EVM) support, so compatible DApps running on Ethereum can also be contracted on Agora.
BOASwap DEX Protocol: A continuous, non-upgradable smart contract that creates an automated market maker facilitating the formation and exchange of the P2P market for ERC-20 tokens on Agora.
BOASwap Bridge Protocol: An atomic swap smart contract that allows reliable swaps between Ethereum Mainnet and Agora Mainnet. Coins can be swapped while fixing the supply of BOA coins through pegging and de-pegging.
BOASwap Bridge relay node: It operates as a bridge relay node connected to each network of Ethereum Mainnet and Agora Mainnet. It supports an atomic swap of bridge protocols to run on each network.
BOASwap Interfaces: Web interface that allows easy interaction with BOASwap DEX Protocol and Bridge Protocol. The interface is one of many ways to interact with BOASwap protocols.
The assets shown here show the coins and tokens that you have on the network that you are currently connected to. Tokens and points that can be displayed are tokens with the ERC-20 token standard and they can be trusted if they are managed in a separate list. In order for My Assets to display the tokens you have, your Metamask wallet must be connected to the Agora Mainnet network. You must also have a trusted connection with BOASwap.
Token swapping in BOASwap is a simple way to exchange one ERC-20 token with another. The user selects an input token and an output token. This specifies the input amount and the protocol calculates the amount of output tokens they will receive. You can then run the swap with a single click and receive the output token in your wallet immediately.
The BOASwap Pool is a liquidity pool for the BOASwap DEX Protocol. Each BOASwap Liquidity Pool is a trading place for a pair of ERC20 tokens. For Pool to facilitate transactions, someone must supply the pool with an initial deposit of each token. This sets the initial price of the pool.
It connects Ethereum Mainnet and Agora Mainnet blockchain and allows an intermediary transaction. Currently, BOA tokens are supported for coin transfer from Ethereum Mainnet to Agora Mainnet, and this transaction is possible for two-way transactions (two-way pegging).
BOSAGORA Agora BOA: It is the default currency for Agora networks and is used for value exchange and network gas fees.
Ethereum MainNet ERC20 BOA and Agora Mainnet BOA exchange rate is 1BOA = 1BOA
When it comes to setting up an integrated development environment (IDE), programming applications on Agora is similar to programming any other software project. There are many options to choose from, so at the end of the day, pick the IDE or code editor that best suits your preferences. Most likely the best IDE choice for your Agora development is the IDE you already use for traditional software development.
For this purpose, every Agora client implements the JSON-RPC specification, so there are a uniform set of that applications can rely on.
- A simple Ethereum wallet implementation and utilities in Golang
First, let’s explain the names used in the .
Ethereum MainNet ERC20 BOA: It is an ERC20 smart contract token on the Ethereum network and is currently listed on the Coin Exchange.
- Web-based IDE with built-in the static analysis, and a test blockchain virtual machine
