TL:DR for exchanges and wallet operators:
https://docs.solar.org/core/updates/3.3.0/
Last night around 2.30 AM (to be specific, at block 671,988) a series of new features went live on the Solar mainnet. In this blog post, we will inform you about the most important new features in a summary. You can find the full list of changes on our documentation site.
As you know, public on-chain governance is a major pillar for the Solar project, together with our planned move to a decentralised autonomous organisation (DAO) later this year. Our first on-chain vote has been carried out and its results implemented in Solar Core 3.3.0.
Development fund (link)
The development fund has been integrated as a flexible framework to automatically allocate a percentage of block rewards to fund aspects of future development. Due to the nature of this change, a governance vote seeking approval was held among all active delegates that were forging at the time, and was overwhelmingly approved by 89% of the delegates. The full proposal and breakdown of votes can be seen in a front-end interface here. For context, no public sharing or contributing delegates rejected the proposal as only one entity representing two private delegates rejected it. The approved proposal decided to allocate 5% of block rewards for this funding.
It is important to note that this does not increase inflation or change the amount of SXP produced per block, per round or per year. Rather, it takes 5% of the current block rewards and redirects it towards a wallet for the future development of Solar. This does mean that the rewards delegates receive, and therefore the rewards they may share with their voters, are also automatically reduced by this amount. In the below table, you can find the new block rewards per delegate rank.
Improved security with BIP340 Schnorr implementation (link)
In an earlier release, we already included a new Schnorr implementation adhering to BIP340 standards. This implementation further improves our security through the way transactions and messages are signed and bumps our transaction version to 3. Older transaction types will be discontinued in an upcoming release.
Vendorfield allowed in all transaction types (link)
To improve the flexibility of our blockchain core, we now allow for all transaction types to contain a vendorfield message. This field can, for example, be used by voters to explain why they vote or unvote a delegate; by vendors to include product information such as its origin, where its components were sourced or what route it traveled before ending up in a store; by game studios to include in-game transactions or simply as a way to attach a note to a transaction.
API updates increasing UX and enhance exchange integration
Wallet addresses will now be verified based on their address when they have not received or sent transactions, which makes integrations and validation of addresses easier for exchanges. Furthermore, the last block ID string is now returned rather than the whole block when querying a delegate through the API, which improves data reliability and a voters attribute has been added to show how many voters a delegate currently has.
Bug fixes
This release addresses several bugs, most importantly a more resilient fork recovery to give nodes a quicker response time when they lose consensus due to issues such as receiving a bad block or delayed broadcast. This means nodes will now rejoin the blockchain quicker, providing a better experience to our end users.
Maintenance
Several minor changes were made to improve the user experience of the wallet, allow for a better user experience with the upcoming Solar Ledger app, and to improve block handling by our network. Additionally, upstream wallet support has been removed meaning users are now required to use our own Solar Desktop Wallet which ensures we can ensure our high quality standard reaches all end users.