About updated 1.5

The updated version 1.5 implies a complete rejection of the utility and the transition to automatic distribution of stake and unstake in accordance with the weight system. Users will no longer choose which dapps they want to support. The value of the stake in each dapp will be determined automatically in accordance with the rules of the application. Governance functionality for voting for dapps will be added in the future, thanks to which users themselves will be able to influence the weights of dapps.

The collection of rewards from all dapps will be done by the first user in the era.
The calculation of rewards for each user will be carried out at the claim, taking into account the pre-calculated coefficients of rewards and balances per user at the time of each era.

Rewards for all dapps are distributed evenly, according to the concept of DappsStaking.

Mapping eraBalance is used to store user balances in each era so that rewards can be calculated for users at any time. Rewards are accrued only if the user has staked at least one whole era. For example, if a user stakes during era 3, then his balance will participate in era 4, and in era 5 he will be able to receive rewards for era 4 from this balance.

In addition, the fee for a claim may differ for different users, depending on the availability of the relevant NFTs. To implement this logic, the nftDistributor contract was developed.

Update changes

• Rejection of the concept of a utility and, as a result, the rejection of the NDistributor contract. Now all rewards are accrued only from the nASTR token.

• Refusal of the unique discount from NFT. Now any nft gives a reduced commission on all rewards, since there is no longer a division into utilities.

• Transition to a system of automatic distribution of stake and unstake between dapps in accordance with the weight system.

The weighting system works in such a way that the ratio of the number of tokens staked in dapps will eventually try to match the set weights.

Example 1:
300 staked in dapp1, 700 staked in dapp2 (then dapp1 owns 30% of the tokens, and dapp2 70%)
We set the weights to 0.7 for dapp1 and 0.3 for dapp2.

Then in the case of a stake of 500 tokens: 800 dapp1 and 700 dapp2.
Next time staking 1000 tokens: 1750 dapp1 and 750 dapp2 (set weights have been reached)

Example 2:
300 staked in dapp1, 700 staked in dapp2 (then dapp1 owns 30% of the tokens, and dapp2 70%)
We set the weights to 0.7 for dapp1 and 0.3 for dapp2.

Then in the case of an unstake, 500 tokens: 300 dapp1 and 200 dapp2.
Next time unstaking 200 tokens: 210 dapp1 and 90 dapp2 (set weights have been reached)

About DappsStaking

DappsStaking module is an ASTAR blockchain precompiler that allows users to stake into dapps they want to support. For this, users receive rewards and the dapps themselves also receive small rewards.

All rewards are distributed among all dapps evenly and their number depends only on the staked balance.

More details can be found with DappsStaking here:

• Interface: https://portal.astar.network/#/astar/dapp-staking/discover
  
• Docs: https://docs.astar.network/docs/dapp-staking/
  

All ASTAR precompiles you can seen here https://docs.astar.network/docs/EVM/precompiles

Smart-contracts

LiquidStaking diamond

Contains 6 contracts

Used to interact with the DappsStaking module to stake into different dapps. The distribution of stake and unstake between dapps occurs automatically in accordance with the rules of our application.

• LiquidStaking.sol

Contains 75 lines of code including comments and spaces

The main contract of the diamond architecture. Contains a proxy implementation.

• LiquidStakingStorage.sol

Contains 167 lines of code including comments and spaces

Used to store storage. This contract is inherited by all contracts of the diamond architecture.

• LiquidStakingMain.sol

Contains 558 lines of code including comments and spaces

Stores the core logic of the LiquidStaking architecture.

• LiquidStakingMisc.sol

Contains 144 lines of code including comments and spaces

Stores the helper functions of the LiquidStaking architecture.

• LiquidStakingMigration.sol

Contains 18 lines of code including comments and spaces

Now it does not contain any logic. Used to store logic related to data migration from variables and structures during contract upgrades. Migration features will be added later.

• LiquidStakingManager.sol

Contains 167 lines of code including comments and spaces

Used to store and manage function selectors and get the address of the implementation contract corresponding to the selector.

• NFTDistributor.sol

Contains 539 lines of code including comments and spaces

Contract to tracks the balances of DNT tokens from users who own NFT as well as their commissions and fees.

• ArthswapAdapter.sol

Contains 430 lines of code including comments and spaces

• ZenlinkAdapter.sol

Contains 479 lines of code including comments and spaces

The adapter contract is used to interact with Algem partners. Through it, the user can use his funds to earn additional income by selecting the application. After the user transfers funds and tokens to the adapter, they are sent to the partner's contract and start generating income, which is recorded on the balance of the adapter. The adapter monitors the user's balances and, upon request, withdraws the user's funds and their rewards. The adapter concept was introduced to improve the reliability of the Algem application and eliminate some vulnerabilities.

• AdaptersDistributor.sol

Contains 106 lines of code including comments and spaces

A simple contract to keep track of the user's balances in adapters in each era. With any changes in the user's balance in the adapters, updates the user's data in the LiquidStaking contract.

• NASTR.sol

Contains 130 lines of code including comments and spaces

ERC20 LP token that is credited after staking.

• Algem721.sol

Contains 111 lines of code including comments and spaces

ERC721 token giving a discount.

Tests

Fot tests connect http://80.78.24.17:9933 endpoint (id: 4369) or build astar-collator local chain.

If you are connecting to our endpoint, your hardhhat config should contain:

...
networks: {
    hardhat: { },
    shidenLocal: {
        url: "http://80.78.24.17:9933",
        chainId: 4369,
        accounts: [`${process.env.PKEY}`, `${process.env.PKEY2}`],
    },
}
...

ASTAR chain nuances

1. In order for the DappsStaking contract to return rewards, you need to call the function DAPPS_STAKING.set_reward_destination(DappsStaking.RewardDestination.FreeBalance). If this is not done, the rewards received from the claim will be staked immediately. This is done once and is implemented in the setting() function of the LiquidStaking contract. The function exists only for tests, since it has already been called and removed on the main contract.
2. All interactions with DappsStaking can only be done if the DAPPS_STAKING.unbond_and_unstake(), DAPPS_STAKING.withdraw_unbonded(),DAPPS_STAKING.claim_dapp() functions are called in the current era, otherwise it will be reverted.
3. Often the ASTAR network does not return a description of the error, returning just VM Exception while processing transaction: revert. This is quite inconvenient and makes debugging very difficult. Basically, these are errors caused by the DappsStaking module. But it can also be caused by variable overflow/underflow or division by zero.
4. In addition, the ASTAR network sometimes just aborts a transaction and causes an error. In such cases, you need to try calling the transaction again or run the tests again.

Test nuances

1. Since the tests are running on a real-time LAN, there is no way to use beforeEach() in tests and all tests are run sequentially.
   
2. Regular EVM addresses and their private keys are suitable for running tests (as in MetaMask).
   
3. It is not possible to run the main tests on a hardhat network or similar networks, since the ASTAR network uses the DappsStaking module precompiler, the code of which is implemented in Rust.
   
4. In order to be able to stake in a dapp through the DappsStaking module, you first need to register it. Since the latest updates to Astar-collator, registering a dapp can only be done using sudo access, so registering a dapp via a function call will fail. You can register dapp by following the link http://80.78.24.17/#/sudo . To do this, select dappsStaking and register(developer, contractId) in the drop-down lists and choose any of the available accounts. Then select Evm and enter the address of the dapp. Only one dapp can be registered per account! To register a dapp, you need to have money on the account balance. To top up account balance, go to Accounts->Transfer and transfer funds from any of the default accounts (Alice, Bob, Charlie, etc) which have a default balance. Remember that if several dapps are used in tests, then they all need to be registered in DappsStaking! If you run out of accounts, you can create them in the Accounts tab.
5. Before each launch of the test chain, you need to redeploy all contracts. To deploy contracts, enter your addresses in hardhat config and replenish their balances.

Deploy old version

Deploy scripts located in scripts/audit/deploy.ts
Addresses of deployed contracts are stored in config/audit/cfg.json
Used constants are stored in config/audit/consts.json

After deployment, it is necessary to register contracts in dappstaking.
Before each launch of the deployment script, you must delete the file unknowk-4369.json from .openzeppelin folder.

deployment example:
npx hardhat run scripts/audit/deploy.ts --network shidenLocal

Upgrade

upgrade example:
npx hardhat run scripts/update/deploy.ts --network shidenLocal

Notes

1. Unused variables. In some smart contracts, unused variables are found that cannot be deleted due to the use of a proxy (you cannot violate the storage state). Often they are labeled /* unused and will removed with next proxy update */. Or /* 1 -> 1.5 will removed with next proxy update */, if the variable will only be used when switching from erashots.