Error occured! Please try again!. @@ -1025,7 +1025,7 @@ function Campaign({ projectNumber }: CampaignProps) { description: `Donate ${value} MATIC`, }); } catch (error) { - console.log("errror >>> ", error); + console.log("error >>> ", error); } }; @@ -1074,7 +1074,7 @@ function Campaign({ projectNumber }: CampaignProps) { - {/* if error occures display text to try again */} + {/* if error occurs display text to try again */} {isError && (
Error occured! Please try again!. diff --git a/pages/scaling-services-sidechains/bnb-sidechain/faq.mdx b/pages/scaling-services-sidechains/bnb-sidechain/faq.mdx index ab182ab6e..6d0ac0111 100644 --- a/pages/scaling-services-sidechains/bnb-sidechain/faq.mdx +++ b/pages/scaling-services-sidechains/bnb-sidechain/faq.mdx @@ -9,7 +9,7 @@ No, BNB Sidechain is permissionless. We have 3–4 games in the test pilot stage ### What is the consensus mechanism for BNB Sidechain? TL;DR: Think of it as a "mini BNB Smart Chain". -BNB Sidechain uses Parlia consensus of BNB Smart Chain. Parlia is a Proof-of-Stake Authority (PoSA) consensus algorithm for BNB Smart Chain. It incorporates elements from both Proof-of-Stake and Proof-of-Authority. It is a BFT-like consensus where only one validator produces a block and to be sure of the correctness of this operations we must wait for the confirmation time, usually its 2/3*N+1, where N is active validators (15 blocks for the current configuration). +BNB Sidechain uses Parlia consensus of BNB Smart Chain. Parlia is a Proof-of-Stake Authority (PoSA) consensus algorithm for BNB Smart Chain. It incorporates elements from both Proof-of-Stake and Proof-of-Authority. It is a BFT-like consensus where only one validator produces a block and to be sure of the correctness of this operation we must wait for the confirmation time, usually its 2/3*N+1, where N is active validators (15 blocks for the current configuration). For more detail, read about Parlia on [Binance docs](https://docs.binance.org/smart-chain/guides/concepts/consensus.html#consensus-protocol). @@ -66,4 +66,4 @@ If you use it as a PaaS at Ankr, we are going to provide the maintenance. We wil ### What's the expected technological advancement here? In other words, what's the positive-sum net value for users and developers? With BNB Sidechain, developers are able to set up and run a scalable blockchain solution, with smart contracts capability, in a very short time. They can also modify and upgrade their BNB Sidechain using different modules or writing their own modules. Effectively, it means faster and simpler monetization and easier user attraction. -With BNB Sidechain, users can gain access to new projects faster and use new exciting opportunities. \ No newline at end of file +With BNB Sidechain, users can gain access to new projects faster and use new exciting opportunities. diff --git a/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc20-token.mdx b/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc20-token.mdx index b18a80350..dec233284 100644 --- a/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc20-token.mdx +++ b/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc20-token.mdx @@ -2,7 +2,7 @@ import { Callout } from "components"; # Deploy ERC-20 token -Deployment of ERC-20 token can be done though Remix IDE of locally using truffle. +Deployment of ERC-20 token can be done though Remix IDE locally using truffle. Since BNB Sidechain has EVM & Web3 support, it is compatible with Ethereum development toolsets. Remix is the easiest way to deploy the ERC-20 smart contract into a BNB Sidechain network. diff --git a/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc721-token.mdx b/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc721-token.mdx index b676bbf62..d4415f82c 100644 --- a/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc721-token.mdx +++ b/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/deploy-erc721-token.mdx @@ -2,7 +2,7 @@ import { Callout } from "components"; # Deploy ERC-721 token -Deployment of ERC-721 token can be done though Remix IDE of locally using truffle. +Deployment of ERC-721 token can be done though Remix IDE locally using truffle. Since BNB Sidechain has EVM & Web3 support, it is compatible with Ethereum development toolsets. Remix is the easiest way to deploy the ERC-721 smart contract into a BNB Sidechain network. diff --git a/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/launch-bnb-sidechain.mdx b/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/launch-bnb-sidechain.mdx index 1ac73ed84..6a3224be8 100644 --- a/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/launch-bnb-sidechain.mdx +++ b/pages/scaling-services-sidechains/bnb-sidechain/how-to-launch/launch-bnb-sidechain.mdx @@ -6,7 +6,7 @@ import { Callout } from "components"; Set up and run a BNB Sidechain instance using the [devnet repo](https://github.com/Ankr-network/bas-devnet-setup). Before running an instance you must do following: -* Ensure you have a dedicated machine that have at least 8 dedicated CPU core and 32GB RAM, as it needs to run 7 nodes. +* Ensure you have a dedicated machine that has at least 8 dedicated CPU core and 32GB RAM, as it needs to run 7 nodes. * Make sure you have a wildcard domain `*.example.com` set to your machine (use a dedicated machine with a public IP). * Modify the `config.json` file to update parameters as you need (you can find all addresses in the keystore folder). @@ -19,14 +19,14 @@ The [config file](https://github.com/Ankr-network/bas-devnet-setup/blob/devel/co * `systemTreasury` — address of system treasury that accumulates 1/16 of rewards (might be governance). * `consensusParams` — parameters for the consensus and staking. * `activeValidatorsLength` — suggested values are (3k+1, where k is honest validators, even better): 7, 13, 19, 25, 31... - * `epochBlockInterval` — length of an epoch, specified in blocks; recommmended length is 1 day (86400/3=28800, where 3s is block time). + * `epochBlockInterval` — length of an epoch, specified in blocks; recommended length is 1 day (86400/3=28800, where 3s is block time). * `misdemeanorThreshold` — after missing this amount of blocks per day validator losses all daily rewards (penalty). * `felonyThreshold` — after missing this amount of blocks per day validator goes in jail for N epochs. * `validatorJailEpochLength` — how many epochs validator should stay in jail (7 epochs = ~7 days). * `undelegatePeriod` — allow claiming funds only after 6 epochs (~7 days). * `minValidatorStakeAmount` — how many tokens validator must stake to create a validator (in ETH). * `minStakingAmount` — minimum staking amount for delegators (in ETH). -* `initialStakes` — initial stakes fot the validators (must match with validators list). +* `initialStakes` — initial stakes for the validators (must match with validators list). * `votingPeriod` — default voting period for the governance proposals. * `faucet` — map with initial balances for faucet and other needs. @@ -59,7 +59,7 @@ DOMAIN_NAME=dev-02.bas.ankr.com make all The variable `DOMAIN_NAME` should be set to your domain. -Deployed services can be access though next endpoints: +Deployed services can be accessed through next endpoints: * https://rpc.${DOMAIN_NAME} (port 8545,9546) - Web3 RPC endpoint * https://explorer.${DOMAIN_NAME} (port 4000) - Blockchain Explorer * https://faucet.${DOMAIN_NAME} (port 3000) - Faucet diff --git a/pages/scaling-services-sidechains/bnb-sidechain/staking.mdx b/pages/scaling-services-sidechains/bnb-sidechain/staking.mdx index 0b83cfcfb..1f1154836 100644 --- a/pages/scaling-services-sidechains/bnb-sidechain/staking.mdx +++ b/pages/scaling-services-sidechains/bnb-sidechain/staking.mdx @@ -12,7 +12,7 @@ Staking roles are: ## Validator Validator is a node that runs the validator node software, in a special validator mode. This mode allows the node to connect to bootnodes and produce new blocks. -Once a block is produced by a validator, it propagates it though the network, using bootnodes, to other validators. Other validators must verify and set this block. +Once a block is produced by a validator, it propagates it through the network, using bootnodes, to other validators. Other validators must verify and set this block. Today the Parlia consensus engine doesn't support fast-finality, this feature is still under development, that is why to prove the correctness of the produced block, the user must verify 2/3*N+1 blocks. To become a validator, the user must fit these requirements: @@ -28,9 +28,9 @@ One slashing is equal to one missed block in the blockchain. If a validator misses a block, another validator can slash them. They don't receive rewards for the missed block. -If a validator misses blocks for `misdemeanorThreshold` times, such validator losses rewards for entire epoch. The default value of `misdemeanorThreshold` is 50. +If a validator misses blocks for `misdemeanorThreshold` times, such validator loses rewards for entire epoch. The default value of `misdemeanorThreshold` is 50. -If validator misses blocks for `felonyThreshold` times, such validator goes to jail and is not able to produce rewards for `validatorJailEpochLength` epochs (usually its around 1 week). The default value of `felonyThreshold` is 150. +If validator misses blocks for `felonyThreshold` times, such validator goes to jail and is not able to produce rewards for `validatorJailEpochLength` epochs (usually it's around 1 week). The default value of `felonyThreshold` is 150. As a result, a jailed validator loses all their rewards for 1 week or 25% of monthly rewards. @@ -73,13 +73,13 @@ Each transaction has execution cost and 15/16 of this cost goes to the validator Not all block rewards go to the validator's owner. A share of them is also distributed between delegators. When the validator's owner creates a new validator, the commission rate must be specified. -The commission rate defines what percentage of the block reward go to the validator owner. +The commission rate defines what percentage of the block reward goes to the validator owner. The rate is encoded as `uint16` and the percentage is encoded as `N%*100`. For example, `0.01%*100=1` and `99%*100=9900`. -It also means the commission rate must be in range from `0%` to `99.99%`. However, in reality, its limited to `0%` up to `30%` to restrict validators from setting very high commission rates. +It also means the commission rate must be in range from `0%` to `99.99%`. However, in reality, it's limited to `0%` up to `30%` to restrict validators from setting very high commission rates. ### Delegator's rewards Delegators rewards are calculated based on their total staked amount at the validator. The universal formula for delegator's reward distribution is `=rewardsPerBlock*myDelegatedAmount/totalDelegated`. -The reward is calculated per one validator. The total rewards for a delegator, if staked at different validators, is the sum or per-validator rewards. \ No newline at end of file +The reward is calculated per one validator. The total rewards for a delegator, if staked at different validators, is the sum or per-validator rewards. diff --git a/pages/staking-for-developers/dev-details/ftm-liquid-staking-mechanics.mdx b/pages/staking-for-developers/dev-details/ftm-liquid-staking-mechanics.mdx index 84a3d9e89..7b82c7835 100755 --- a/pages/staking-for-developers/dev-details/ftm-liquid-staking-mechanics.mdx +++ b/pages/staking-for-developers/dev-details/ftm-liquid-staking-mechanics.mdx @@ -25,7 +25,7 @@ The requirements when unstaking are: ## Fees When staking, the user pays no technical service fee. -Unstaknig applies a `burnFee` that depends on the current liquidity and amount to unstake, and is calculated by the `FantomPool` smart contract. +Unstaking applies a `burnFee` that depends on the current liquidity and amount to unstake, and is calculated by the `FantomPool` smart contract. The fee is deducted from the withdrawn amount. The user must also count in the gas price for outgoing transactions. @@ -78,4 +78,4 @@ The workflow is both user and Ankr-driven. The user part is Step 1, the Ankr par 2. If the transaction is successful, aFTMbs are automatically burned and removed from the user’s address. An event `TokensBurned(address indexed account, uint256 amount, uint256 shares, uint256 burnFee, uint256 indexed wrId)` is emitted, and the user receives `amount - burnFee` FTM within the period of up to 35 days. The fee depends on unstaked amount and can be shown to the user via `getBurnFee(uint256 amount) external view returns (uint256)`, which changes from time to time based on the current available liquidity. -3. Then `FantomPool` saves the request in the form of a `WithdrawalRequest {address payable staker; uint256 amount;}` struct. Within up to 35 days the Ankr backend calls `withdrawLast()` to send the staked funds back to the user, and a `Withdrawn(address indexed staker, uint256 amount, uint256 indexed wrId)` event is emitted. \ No newline at end of file +3. Then `FantomPool` saves the request in the form of a `WithdrawalRequest {address payable staker; uint256 amount;}` struct. Within up to 35 days the Ankr backend calls `withdrawLast()` to send the staked funds back to the user, and a `Withdrawn(address indexed staker, uint256 amount, uint256 indexed wrId)` event is emitted.