By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts.
Over 18,500 users, continues testing and upgrading, and many more interesting testnet review.
Looking back, we couldn’t have anticipated such a large and active participation in the rollout of our application on the testnet. We really appreciate this input from our community.
Many thanks to everyone who joined us in trying out our protocol and for all those great comments shared on our Discord channel.
Over 18,500 users, including you, purchased cover policies and provided liquidity to cover pools on our platform. We’re impressed to see how active you were in reporting and voting on incidents as well as participating in our staking pools.
The tutorial videos we published on our YouTube channel were viewed over 5k times. We will continue to add new types of content to our channel so don’t forget to subscribe to get the latest Neptune Mutual updates.
The Neptune Mutual testnet has without a doubt exceeded our expectations. Thanks to you!
Your feedback helped us refine and improve our application as we move towards our launch on the mainnet.
Over the weeks between our testnet launch, March 10th, and the end of our Gleam competition, April 10th, our users’ feedback helped us develop and significantly improve the Neptune Mutual protocol — this underlines to us the importance and value of our active community.
Hence why we’re so excited to reward our most active testnet users — results to be announced in May. This is our way of rewarding our community for their steadfast feedback and support.
While we wait to find out who our 100+ lucky winners are…
Let’s go on a quick run-through of everything that’s happened to date on the Neptune Mutual testnet:
After receiving a much higher than expected number of testnet users, the massive spike in traffic overloaded our database servers and sent our application offline for a couple of hours.
We upgraded our database hosting plan to allow much higher traffic, and got the application back up and running.
As our database size became larger, we kept making several performance tunings and query optimizations.
2. Our Team Added a Subgraph Bridge to Avert Future Indexing Issues#
We’ve been using The Graph protocol for indexing blockchain events and we faced some indexing issues that made the application sluggish when reflecting the amount of liquidity provided and policies purchased. On one occasion, the Graph protocol also suddenly went offline for a few hours.
The Graph protocol going offline was something we never bothered to think would happen. We had to come up with a solution fast to avoid these issues again arising in the future. We quickly built a subgraph bridge that caches known events to ensure that our applications remain available even when The Graph is temporarily down.
3. Ropsten Was So Slow We Switched to Polygon Mumbai#
The Ropsten network has always been our preferred test network choice as it is similar to the (current) Main Ethereum Network. The primary reason to deploy our protocol on Ropsten was to check and see how our protocol functions in a multi-user and close to the real-world environment.
Interestingly, we witnessed frequent reorgs in the Ropsten network. Transactions that were included and confirmed having more than 50 confirmations disappeared from Etherscan. The Ropsten network was relatively unstable during full load than what we experienced using it earlier.
Many users commented on the performance issues they experienced using the Ropsten network. Users who purchased policies saw their cxTokens disappear after an hour. The platform’s TVL kept fluctuating up and down even when a steady flow of liquidity was added. The reorgs not only affected our application but also the hosted subgraph. As a result, users who collected points on the leaderboard also saw their points disappear frequently. Overall, the network was slow and unreliable.
Because of this, we switched to a faster and more reliable test network, Polygon Mumbai. Once we deployed our protocol in Mumbai, the user experience became relatively stable. There were no longer any reorg issues and, as a result, no more reindexing issues and transactions disappearing.
We updated our UI/UX design to enhance the Neptune Mutual experience.
In particular, we improved the transparency and labeling of the status of transactions on the protocol. To make it easier to identify if a transaction is in progress or if it has been completed successfully.
We achieved this by using unique icons for each different status of the transactions.
Based on user feedback, our team added an icon to display the policy status, disabled the ‘purchase cover’ and ‘provide liquidity’ features when a cover is in its reporting period, and the cover status is now shown on almost every page on the platform.
We also added an icon for the process of adding tokens to a user’s MetaMask wallet.
As a global community-driven protocol, we place huge importance on making sure users get access to the platform in their native language.
That’s why we added a multi-language support feature so that our users can access Neptune Mutual in their native language wherever they may be in the world.
Although this is still a work-in-progress, we’re proud to say we’re going all-in on this.
We improved our platform’s transaction error handling to avoid future complications when it comes to transactions.
We believe that hiding blockchain error messages is not a good design and therefore added a function to forcefully send a possibly failing transaction. The failed transactions were helpful in debugging why such an error occurred.
9. Updated Real-Time Display of Balance and Allowance Data#
Balances and allowances now display more accurately, in real-time after a user performs an action.
Added accrue interest feature: brings the earned interest from lending strategies back to the liquidity pools during unlock cycles.
Added an extra validation mustHaveNoBalanceInStrategies to ensure strategies are empty during withdrawals.
To reduce the deployment size, we moved our vault strategy logic from VaultLibV1 to StrategyLibV1.
Fixed the accounting errors of lent out amount, received amount, and the total amount for any given strategy.
Governance
Fixed a bug in claimsBeingsFrom function so that if a resolution is “Incident Occurred”, the claim period starts immediately. If “False Reporting”, the claim period is set to 0, which means it never starts.
Fixed a bug in unstake feature that allows users to invoke unstake before an incident is resolved, and fixed another issue in the feature of unstakeWithClaim which allows users to invoke unstakeWithClaim even after the claim period is ended.
Added getAttestation, and getDispute to reporter contract and interface, and completed the test coverage for these changes.
Refactored updateCoverCreatorWhitelist to allow access to governance agents instead of a cover manager.
Fixed multiple bugs in getReporter and getResolutionInfoFor functions; added tests to cover governance contracts for setting up roles and admin, and many others.
Cover Lifecycle
Added “whitelisted cover user” feature that allows cover creators to restrict who can purchase cover.
Added an incrementable state variable lastPolicyId emitted upon each cover purchase and WeightSet event to CoverReassurance contract
Renamed multiple functions to improve code readability and dropped obsolete contract interface ICommission, and other redundant functions
Liquidity
Refactored removeLiquidity of the Vault contract to only emit NPMUnstaken when the value is greater than zero; added a function setLiquidityStateUpdateInterval to the LiquidityEngine
Added an event to emit LendingPeriodSet when the lending period is updated; new field certificateTokenIssued & certificateTokenRedeemed to Deposited and Withdrawn event of ILendingStrategy respectively.
Added getLendingPeriods to ILiquidityEngine, and refactored getLendingPeriodKey and getWithdrawalWindowKey on StrategyLibV1 to drop ignoreMissingKey check
Renamed multiple functions, added amount checks on VaultLiquidity, and covered all the changes with appropriate tests.
Policy
Fixed a bug in getPolicyRatesInternal, and refactored setPolicyRatesByKey to ensure only valid cover keys are accepted.
Added a new function calculatePolicyFee to replace the getCoverFee function; renamed getCoverFee to getCoverCreationFeeInfo, and getCoverFeeInternal to getPolicyFeeInternal for added clarity.
Replaced getCoverFeeInfo logic with calculatePolicyFee and dropped the latter, including other obsolete arguments and unused functions.
Added a referral code feature to purchaseCover, and addLiquidity methods; updated the tests coverage.
Bond and Staking Pool
Refactored, and added more tests to complete the code coverage of bond, and staking pool contracts and libraries.
Refactored getName of StakingPoolBase to return correct contract name, createBondInternal of BondPoolLibV1 to remove redundant minNpmDesiredvalidation, and renamed the _getCommitment function to _getBondCommitment for added clarity.
Flash Loan
Refactored flash loan feature to remove redundant addresses, amount validation, and transfer protocol commission after all checks are passed; completed the flash loan code test coverage.
Added a check to ensure calculatePodsInternal is not called during flash loan transactions.
NPM Token
Added new features issueMany and transferMany to NPM token contract.
POD Fungibility
Added feature to allow transferring of PODs to different wallet addresses, claim using that address, and refactoring the codebase to drop maintaining individual account’s liquidity added and removed states.
As a result, the _redeemPods function doesn’t need to update the state and thus the function name is changed to _redeemPodCalculation to signify that it is a read-only function or a view.
A week later, we made our incident report and claim cover payout features available for everyone to try out. During this time, our Discord channel shared pseudo testnet incidents that users could report in real-time.
Our community has helped us achieve and surpass the goals that we set ourselves for our application launch on testnet.
We value the feedback our users shared with us on how we can further develop Neptune Mutual. Based on their review and suggestions, our team has been able to move forward in preparation for the mainnet. Again, thank you.
As a community-centric protocol, we also opened and grew different social media channels where we can connect with our users. An accomplishment that led us to grow our community way beyond our expectations.
Staying true to our mission, we hope that our testnet has shed light on the importance of digital asset protection. Neptune Mutual can help you get covered and be more confident in this new era of blockchain technology.
A good start indeed! But, our work is not done yet.
Also, it’s not too late to experience Neptune Mutual.
We have sent email confirmation. Please confirm to receive our
newsletter.
Unfortunately, something went wrong while trying to complete your
request. Please try again later. If the problem persists, do not
hesitate to let us know through the community channels.
