Community Update S1E1

Today, we are releasing the first iteration of an ongoing series of articles from our team to update our community and anyone interested in our works and efforts around the FLR Finance Ecosystem of products.

Highlights

• We deployed a new version of the FTSORewardManager contract, greatly increasing the accuracy of the WSGB delegation rewards distributions throughout the whole FF platform.
• Optimisation of the data capturing and aggregation in FLR Index. This grants us the ability to provide real-time data for applications like FLR X as well as full trading, price, and chart history in the near future. Utilising this new capability, the FLR X trading UI now auto-updates, providing real-time price information and transaction history.
• SGB/USD price is now submitted through DeFi Oracles to the FTSO Manager.
• We are preparing to deploy a testing version of our platform to Coston. This will allow us to test our products more thoroughly pre-release for a smoother launch process.
• Our node has been scaled up to 5x performance having dedicated support for the North American and European continents. Additionally, we are now supporting a full history node.

In Depth

FTSORewardManager

On March 16th, our team performed a migration to a new version of our FTSORewardManager smart contracts. This update was necessary because prior to Epoch 20, the system did not mirror the logic of the FTSO Manager technology provided by the Flare Network 1:1. Our team resolved this technological debt, and tested the upgrade thoroughly before performing a very successful release. This enabled a 99.934% accurate reward distribution for pending SGB rewards.

Since then, we have been monitoring the performance of our FTSORewardManager. On Saturday, March 27th, our team noticed an anomaly that was related to the Manager connected to the WSGB side of the Loans Platform. The anomaly has since been resolved.

We are continuing to monitor the performance of the Manager and have created an internal tool which will allow us to monitor and distribute rewards with a high degree of accuracy. Once stability is ensured, full automation for rewards distribution will be implemented.

FLR Index & FLR X

On March 10, we deployed an update to the front-end of the FLR X protocol. This update allows users to see the real-time price action on the chart as well as the trading history. Previously, real-time updates were not possible as our system was analysing all transactions within every block for pertinent data and then storing it to a database.

For FLR X, the relevant data was the swaps. Through saving and analyzing every single swap, we were able to know the price for every single pair at any point in time. With that data, an aggregation to the database made it possible to provide candle charts to our users, the price at the time they would load the page, as well as trading history, personal trading history, and much much more. At the time we were designing this tool (November 2020), we had not anticipated the volume of swaps, blocks, and other information which we would need to save to our databases. Eventually, users faced some performance issues due to the large volume of data we were required to collect and parse. We also wanted to scale, provide more functionality and possibilities for the future! We have refactored our FLR Index service which will provide fast access to reliable data and will be used across our existing suite as well as upcoming products (Drops, Wrap, and more). We envision this product to be an extremely useful tool for developers, companies, and institutions around the Flare Network community.

DeFi Oracles

On March 20, we deployed a new version of the DeFi Oracles price provider into production. This version includes the additional submission of the SGB/USD ticker to the TSO system. This was very exciting news for us because the SGB price feed for FLR Loans will now be based on a decentralized price provider, rather than our internal price feed. We believe it is extremely important to have community-oriented tools like the FTSOs which are not based on the decisions and data of a single organization. This was also exciting because it was the last step for the State Connector to come to life, allowing agents and other tools to begin working with and expanding the capabilities of the State Connector protocol.

Coston Network testing Suite

Coston created some of the most fun times for both us as a development team and a lot of our community members. It was a place for people to learn and educate themselves in a safe environment. It was also a place for us to try, test, listen to community feedback, implement changes based on that feedback and start the circle over. In our experience as a team, a well-defined development process provides both a much more stable product as well as time for the users to familiarise themselves with changes and provide feedback.

The development cycle within FLR Finance follows these steps:

1. A developer or a team receives the specifications and design (if applicable) from one of the project managers.
2. The developer(s) define tasks/deliverables based on number 1.
3. Local development work begins.
4. As deliverables are completed, the changes are deployed to the development environment.
5. In the development environment, these deliverables are tested by the project manager and other team members.
6. If the deliverables are approved to be correct and stable, they are then deployed to the staging environment where these changes are further tested by our team of moderators. If the deliverables are not approved, they head back to the developer and repeat step 3. It takes only one objection from any team member for the developer to revert.
7. If all criteria are successfully covered and the deliverable passes testing by the Project Manager, team members and moderators, the deliverable is scheduled for a production release on the next release date.
8. The deliverable is released to the users to further improve the FLR Finance product suite.

This process can be summarised in 3 main steps: Development, Staging, and Production. This gives us the ability to minimise the chance of error, anomaly, or unexpected edge case.

In the blockchain world, each Network allows for its own version of this development process. On the Flare Network, we break it down as follows:

Coston, the development network, where developers are free to test things out and deploy new technology more easily due to no real token value.

Songbird, the staging network, where ideas and concepts are tested against the real world, with real value at stake; a check for anyone who needs to see how an idea and product will hold up against market forces.

Flare Network(Mainnet), the production network, where all the efforts from the above are brought together to live long and prosper. This will be the culmination of all the above efforts taking their final shape as the community have tested, voted on, changed and finally accepted them.

Our products on each of those networks go through their own iterations of the 8 step development process listed above. With the re-launch of Coston, this means that by the time a change is made to our product suite on the Flare Network Mainnet, it will have gone through a 24 step development process.

Performance and Non-Human updates

Since the beginning of our journey on the Songbird Network, we have learned an unbelievable amount of information. We started with one very small node connecting our dApps and our users. We have grown exponentially since then and as of Monday the 28th of March, we are now providing full continent support for both Europe and America with 99.8% uptime availability. We have been continuously improving our infrastructure and this latest node update has further increased our ability to optimise performance.

We have also performed an update on all of our frontend infrastructure. This will not affect you as a user directly at the moment, however, it is a large, noteworthy infrastructural update which will make it much easier to perform tests across platforms.

Upcoming

Delegation rewards before Epoch 20: Analysis is ongoing to address the inaccurate delegation reward distributions from Epochs prior to Epoch 20. There will be an announcement when this process is complete regarding the decisions pertaining to this matter. Any adjustment needed will be a universal adjustment that does not require any information from the user.

DFLR competition: We have established our base list of DFLR winners for the DFLR competition, but analysis of wallet activity to determine bad faith transactions is ongoing. Winners will be announced, and rewards given out as soon as this process is complete.

Testing instance of FLR Finance products: FLR Finance dApps will also have a home on the Coston Network in light of our new development process. All of our new releases will start off on the Coston Network so our development team, moderators and any interested community members would be able to participate in the ecosystem through a test network.

EXFI Loan bug: Some weeks ago, a series of pump and dump schemes caused a significant drop in EXFI loan TCR leading to a roll up of all EXFI loans during Recovery Mode. The single remaining nest was eventually hit with a liquidation transaction which bugged due to an empty stability pool and nowhere for the loan to redistribute. The bugged transaction resulted in the loan no longer being able to be targeted by liquidation transactions. As a consequence, the TCR of the EXFI loans system is almost wholly determined by the ICR of a single un-liquidatable nest. On the other hand, this bug has meant that the EXFI loans system can be used to create new nests without having the larger loan be immediately redistributed. We are working with with our auditors, CommonPrefix in order to find the best solution to this issue.