[Proposal] Aurora Validator Admin Change and NEAR Tokens Allocation

This proposal consists of two parts: changing the administrator of the Aurora Validator and allocation of the accumulated NEAR tokens within next year to support development of Aurora protocol to Aurora Labs.

At the moment Aurora Validator is run by Aurora Labs (hardware) and managed (administered) by Aurora DAO. Being a complex process, management of the validator results in a multitude of complex transactions to be send from Aurora DAO to validator contract (see proposals id #31, #32, #33, #34). Such transactions should undergo detailed examination and validation, which is possible only in the case of in-depth understanding of the staking farm validator contract and NEAR Runtime, which might be out of competences of some of the Aurora DAO councils. On a separate note, the amount of transactions required for proper management of a validator is in the tens. This creates an unnecessary load on the DAO Councils.

We propose to change the controlling wallet/address of Aurora Validator aurora.pool.near from auroradao.sputnik-dao.near (Aurora DAO) to aurora-dao-bvi.sputnik-dao.near which is official address of the Aurora DAO service entity Aurora DAO Ltd (BVI). This would simplify the management of the Aurora DAO Validator, while maintaining the control over the validator in the DAO hands through service entity.

The main reason for the existence of Aurora Validator is having an ability to partially offset the costs of transaction relaying (providing free transactions to Aurora users through Aurora+) and protocol development. Both of the activities are currently performed mainly by Aurora Labs.

We propose to approve the allocation of the validator proceedings (NEAR tokens, generated from PoS consensus algorithm), accumulated within the next year (till 31st of July 2023) to Aurora Labs. Aurora DAO service entity (and, thus, Aurora DAO too) would maintain the full control of validator, while Aurora Labs would be able to directly communicate with the service entity, without creating a constant additional load on the Aurora DAO.


This makes a lot of sense. Ship it!