Charli3 oracle has a node network size of 5. If we can increase the node network, it will increase decentralization, reliability, security, and community engagement.
This is the total amount allocated to CHARLI3: Scaling oracle node operator pools with selector mechanism.
We will expand the quantity of nodes participating in a data feed network beyond 5. Our strategy will be to create a âselectorâ solution to pull from a pool of node operators.
We would be employing a dev shop to assist in delivering this project in a timely manner. Our current in house developers are fully engaged in delivering other projects. We have active contracts with Metalamp, Mlabs, and Txpipe.
SECURITY RISK: This code would not be open sourced due to the security nature of it. The selection of participating nodes for an Oracle cycle is of paramount security and we would not want anyone to be able to reverse engineer this solution to potentially game the node selection system.
The current Charli3 node infrastructure allows up to 5 participating nodes per data feed (eg ada/usd).
However, these are predetermined prior to a price update and the nodes supplying the feed are âhardwiredâ in the feed config file. Adjusting operators requires a multi-signature update of the feed.
We propose to allow a large network of node operators and to build a mechanism for selecting node operators prior to a data feed update. For example, this mechanism may randomly select 5 operators from a larger pool (eg 50) to supply the price feed. At a very basic mvp we will build the selector to randomize who gets selected. Eventually we will enhance the selector mechanism to take into account historical performance, tier level of node, and potentially other variables.
For this proposal, we want to develop a random selector mechanism that is secure such that it is protected from single point attacks to manipulate which nodes get selected. Achieving just this mvp is going to require an experienced architect along with security expert review and significant testing.
Summary of outputs:
By allowing a large pool of node operators, it further allows more members to help run the network and further decentralize the oracle operations. This also allows more users to gain rewards from Charli3 for being node operators.
This expansion of node randomness would also increase security for all projects using the oracle, by not allowing anyone to potentially target the nodes involved in any transaction.
Having this higher level of security will also be beneficial for spreading word of the robustness of Cardano defi oracle security.
Given the extra security of randomness we may also be able to lower node count per transaction and therefor lower costs, allowing easier monetary access to other projects
Capability is high. We are a tried and proven company delivering oracle operations for 1.5 years with 99.99% up time and accuracy on Cardano.
A:
B:
C:
A:
B:
C:
A:
B:
C:
A:
B:
C:
A:
B:
C:
Catalyst close out report submitted and accepted
catalyst close out video submitted and accepted
Charli3 leadership - Damon and Robert
Charli3 Tech Developers
Oursourced team (potentially metalamp, txpipe, mlabs as contractors we have active relationships with right now on or off Cardano)
we propose this will take a minimum of 2 full time developers, a part time scrum manager for the project, and part time architect in the early stage. all over the proposed timeline of about 8 months
Devs ~ 85/hr x 2
Scrum manager ~ 100/hr
Architect ~ 125/hr
Oracle implementations for Defi on CArdano are paramount for securing users funds. There have been 2 major liquidation events on Cardano due to lack of oracle use on Cardano causing 100s of thousands of dollars lost from community members.
additional security to Oracle features help to make the cardano ecosystem a more secure place for users to trust their funds and liquidity