Dear Ambrosus community,
The month has come to an end. In this post, we will go over some of the key updates that happened this month, including the two latest new upgrades. Thank you for your continuous support.
A recurring theme for the month of November has been the active community members following and testing updates, and discovering and flagging miscellaneous points for improvement and bugs.
Since v0.1.10 “Node Extended”, users can set a password and login for validation in the Hermes dashboard, instead of using a private key. Furthermore, per user requests, modifications were made to the Ambrosus Explorer interface. As a result, transaction filtering has been redesigned and additional features have been added, further optimizing the display of accurate transaction, bundle, and masternode data. A lot has been improved in general as we follow the roadmap — the input we receive from you, the community, helps us further streamline and polish things while we keep building. We are grateful for your efforts and continuous support.
Now, December kicks off with a new Explorer Update, version 4.0.18. In this release, the tech team fixed a bug with sorting by balance on Atlas masternodes pages, while also implementing a minor update on the disposition of sub-transactions and “+” button state on the transactions page.
The tech team would like to inform you that Ledger support for native Amber is on its way. Currently, the team is developing an application for storing native Amber in the Ledger wallet and we will release more details regarding this process down the road. Additionally we would like you to know that Amb.to is poised for a complete overhaul and upgrade. The API will be optimized, and the UI/UX will be adjusted accordingly since it’s incompatible with the current network.
Adding to the November overview, the team will continue working on the accuracy of displaying internal and external transactions in the Explorer, as well as implementing new feature requests from the community. Importantly, the masternode private key is currently stored with the node itself, and we plan to offer better security. Therefore we will implement an alternative private key storage solution to increase security.
Next, due to an ideological error incorporated into the design, a bundle can’t be removed from the Atlas masternode (storage masternode) and remains registered with the node. However, the node stops receiving rewards for the respective bundle since the storage period has passed. In such cases, the user is unable to reset the node and can’t transfer the bundle or remove it from the masternode.This leads to a challenge being issued on the transfer of the bundle, but resolving the challenge is impossible for everyone. Each masternode trying to pick up the bundle is charged by the transaction cost.This will be solved by refactoring the smart contracts handling Atlas masternodes.
Another ideological bug that was found is a mistake in one of the smart contracts. In essence, it gets short of rewards to be issued to masternode operators for bundle storage for the last two periods of keeping: the 12th and 13th period. The necessary funds are with the smart contract, yet it miscalculates, thinking there is insufficient funds for the payout.
The team is going to develop an environment specially for masternode operators. In this environment they will be able to monitor their masternode activities, performance and data. This area will be the whale area. If you have any suggestions or ideas in regards to the whale area, don’t hesitate to share them with us. In addition to the topic of community efforts, the same AMBassador behind the Masternode Management Tool for MacBook, recently launched a new community-made tool — a very cool coincidental event! The tool allows you to receive updates from your masternode(s) through a Telegram Bot. Click the link below for more details:
Stay tuned for more!