Charli3 audit Milestone 2 reached!
Project ID: 1100094
Project Name: CHARLI3 — V3 Architecture Audit
Milestone: 2/5
Milestone link: https://milestones.projectcatalyst.io/projects/1100094/milestones/2
The Anastasia Labs team have spent the last 2 months completing an audit of the following parts of the Charli3.io solution:
- On-chain code
- Off-chain node software
- Off-chain charli3 architecture
The audit had a delayed start, but began the first week of June 2024. This phase took 8 weeks to complete with the end results and report completed on Aug 1st 2024.
Download/View the official report from Anastasia Labs here:
Milestone 2 Report — Audit Findings Phase 1
Summary of key findings with Charli3 action plan
The Charli3 team will be implementing most of the recommendations from the Anastasia Labs team. But please find below some notes on specific issues and our action plan.
Impact of key loss in Multisig Transaction
There were several medium to minor issues for the Charli3 team to address, which will become output for the next set of milestones. In particular, the highest issue can be described as requiring 100% of multi-signatures to adjust oracle feed settings (admin). In most cases, the multi-signatures include multiple Charli3 team members and multiple customer signatures. In the case of community feeds, this will involve an assigned administrator on the part of the DAO. Since it requires 100% of all signatures to sign, there is a possibility that a signer loses access to their system or is unable to sign. In that event, the Oracle feed could not be adjusted and run indefinitely until the tokens in the contract are used up completely. The remedy is to adjust the number of signatures required to less than 100%. Note that the process for nodes to validate a data point are not impacted and have an entirely different architecture, without issues. This issue only pertains to the administration of Oracle feed contracts.
Lack of Slashing Mechanism
An automated system is in the research and development phase. Currently customers work directly with Charli3 to administer manual management of node operators (slashing, adding, removing parties).
Missing rate limit and retry mechanism in Node Backend
Data Validation for API responses
In short, this is the initial design decision to ensure node networks are not delayed by unresponsive data sources; no retry is made if a failed attempt is made. We strive for as many data sources as possible and with many feeds have 15+ data sources allowing for a couple to not be included in the case of a failed attempt. The team will implement and test adding a retry feature during the remainder of the audit.
All the nodes use the same set of data providers
Again this is a design decision. Charli3’s networks do not source the “Truth” or “Fact” about the price of ADA/USD. Customers may come to us looking for the “price of ADA/USD” but we are not in the data provider business. The Charli3 solution is a system of decentralized node networks that deliver data from preselected data sources to a target blockchain in a certain format. Charli3’s node networks are a data delivery service. Our team believes that any solution that promotes both to provide truths about the world (data source solutions) and delivery of that data in a decentralized node network is introducing high security risks. For example, node operators may all maliciously select poor quality sources in an attack or incorrect sources. Standards for data sources must be set to some degree by the customer/Charli3 admin team to ensure the highest level of quality but also to set a baseline standard for what is expected for proper node conduct. The choice we made to preselect data sources (with customers approval) is not one we intend to change in the future. To iterate this point, Charli3 is a decentralized network that delivers data securely from point A to point B. Anyone that thinks a Decentralized Oracle Network conjures up and delivers data about the world is conflating two different solutions and introducing significant security risks
