🏁Initial choices and rationals

The followings are the main choices we've done :

1. Decentralization : we build and stay building according to the web3 ethos and promoting the web3 economy. We believe decentralization is one of the major drivers for energy transition and that's why the web 3 ethos is the one needed to accelerate and reach that goal.

2. Permissionless use : We open possibilities of use while keeping the eyes open on regulations. There is no need to authorizations in order to use, technically speaking, Hemergy core but as we enable in some cases, security token issuance, it is important that Developers know the jurisdiction applicable in their country or the countries they are operating in.

3. Revenue and Energy tokens Generation : This is done by our relayer oracle as we will link it to the trusted and certified IoT devices that ensure measurements of the energy or any value produced and its origin, directly on web3.

As we are in an early stage, building and testing, these points could be seen as issues by web3 community :

1. Contracts' upgrades : Hemergy is the only authority that can make upgrades to Hemergy protocol. Later we can move to a DAO structure that enables the community and only the community to upgrade the system.

2. KYC and AML : KYC and AML are operated by specialized third party partners. This happens for now on web2 level and accounts are marked KYCed by Hemergy. The next version will include DID partners and also KYC/AML reliance feature on web3.

3. Authorization : Only KYCed accounts can issue, sell or buy security Meros. Meros are the tokens representing shares or titles of fractional property on renewable energies facilities. Meros can be a security or a utility token. Later, a proof of personhood will be employed in order to protect the community of users if no KYC is needed.

4. Fixed Community Pool Percentage: The community pool percentage is hardcoded and could benefit from being adjustable by governance mechanisms.

5. Permission Checks: The setRevenueGenerationContract function in EnergyToken only checks for onlyOwner, which might be a risk if broader permission control is needed.