## NEAR Protocol 1. Does the protocol offer a standardized web3 library interface? There is standartized library that allows creation of accounts, deployment of contracts, calling contracts, querying contracts state, staking and calculating the current seat price to become validator (https://near.org/papers/economics-in-sharded-blockchain/#validators). JS - https://github.com/near/near-api-js Third party Go - https://github.com/aurora-is-near/near-api-go - I did only small changes to create generate transaction method and staking action method 2. What are the most popular browser-integrated wallets? Do they all support the same API or do we need to target each one individually? The most popular wallets right now seems to be https://wallet.near.org/ which is fully web based wallet. When user tries to interact with dapp, he will be redirected to the wallet to approve the action and then after approve/reject will be returned back to the dapp. In decentralization efforts, NEAR wants to deprecate that wallet and incentivaize people to use different wallets - https://near.org/blog/near-opens-the-door-to-more-wallets/ For this purpose they have developed WalletSelector which allows easy integration using common API of various of different wallets - https://github.com/near/wallet-selector 3. Is there a standardized protocol for interacting with external wallets?Can we drive a key generation process from the browser? We can use WalletConnect to external wallets. Creation of account consist of generating key pair and then submitting a call to special contract to associate your public key with human readable account id - https://docs.near.org/ru/docs/develop/basics/create-account/#fund-your-account https://github.com/near/near-api-js/blob/ef6d7fbf195f0ba4b7c7320423f5907b5cffeff4/packages/cookbook/accounts/create-mainnet-account.js#L27 Most likely it wont work without backend service for account creation. 4. What is the most suitable format for our "raw unsigned transactions"? We can just base64 encode and decode the binary transaction. 5. Are there popular JavaScript solutions for React apps that simplify the DApp development in the particular network? There is npx binary https://github.com/near/create-near-app that lets you quickly create react web app, you can choose React for the frontend template. 6. Does the protocol offer something equivalent to a "staking transaction"? How can we create it (in Go and potentially JavaScript)? There is staking transaction that you can execute to become validator after 2 epochs (https://nomicon.io/RuntimeSpec/Actions#stakeaction). But if you want to let other people delegate stake to your validator. You need to deploy staking smart contract. Staking and delegation docs: https://near-nodes.io/validator/staking-and-delegation Factory whitelisting contract - https://github.com/near/core-contracts/tree/master/whitelist Staking pool factory contract: https://github.com/near/core-contracts/tree/master/staking-pool-factory Staking pool contract: https://github.com/near/core-contracts/tree/master/staking-pool 7. What is the code for signing a raw transaction (in the browser and offline)? I have successfully generated transaction in Go and then signed and sent it from Javascript. 8. What is the most convenient development environment for the protocol? How do you run a local short-lived network simulation and how do you write unit tests for it? Kurtosis (https://www.kurtosis.com/) provides easy way to spin local NEAR testing environment using docker containers - https://docs.near.org/develop/testing/kurtosis-localnet This environment doesn't really spin real validator. To do real world testing in local environment we will have to setup validator following the official guide. Full validator setup - https://near-nodes.io/validator/validator-bootcamp Chunk-only validator setup - https://github.com/Scott-Canning/Deploy-a-NEAR-chunk-validator-on-AWS Chunk-only validator setup - https://vitalpoint.ai/ultimate-guide-near-validator-on-azure/ 9. What are the staking economics of the protocol? How much stake must be attracted before the profits of running a validator exceed the costs. Is there an ideal amount of attracted stake per validator? The answer of these questions would inform our design regarding the creation of a validator pool for the protocol. https://nomicon.io/Economics/Economic#validator-rewards-calculation In current design there seems to be no special amount per validator, you just need to have minimum stake above seat price. Bigger fraction of total staked tokens you have, higher percent of the reward you gonna receive. In 2023 Phase 2 of the sharding protocol will be released, after which there will be no need for validators that produce whole blocks. After this update maybe NEAR will decide to have only Chunk Producer validators to foster decentralization - https://near.org/about/network/decentralize/ 10. How is compounding handled? Do we need to plan some automated processes that will be responsible for optimising the staking ROI? Rewards are automatically restaked. I don't think that we need to do any optimisations ### Potential problems: 1. During transaction creation you have to also specify block hash that is from past 24hrs, if its older than that, then it wont be accepted by the network - https://docs.near.org/integrator/create-transactions#6-blockhash One potential solution is to use something like multisig/proxy contract. During initialization of this contract, we will specify only from what public address to accept signatures. Then when the user signs the transaction we will submit it the contract, parse it, verify the signature and execute the proper stake/withdraw/unstake action. Other solution could be, right before signing the transaction to fetch more recent block hash and replace the old one. Future solution could be implementation of metatransactions on protocol level, which is currenlty in progress: https://github.com/near/NEPs/pull/366 https://github.com/near/nearcore/issues/8075 https://github.com/near/nearcore/pull/7497 2. Unstaking from the staking pool contract is two step process. First the user has to send transaction to request withdraw and when the funds are available, the user has to send transaction to unstake. 3. Failed cross-contract calls could lead to dirty state in the caller contract - https://docs.near.org/develop/contracts/crosscontract#failed-execution 4. For proper local dev environment we will have to create script to setup full validator and deploy all the contracts regarding the stakings pools.