Modules
How we have split the process
API Gateway
Decimal system is API-first, & all these parameters can be directly triggered directly by the client's system. Almost all intents can be triggered via Decimal APIs. This is the primarily mode of communication for Enterprise clients. This will be used to support both institutional and UI intent requests.
The client defines the following as part of his Intent:
The start state
The end state
Trigger condition(s) [optional]
Success criteria(s) [optional]
Speed vs Cost preference [optional - default is Cost]
Job Manager
Job manager creates a new Intent on-chain and an intent-id is created for tracking. Job manager is also responsible for intent validation. This is a mechanism to validate intents before they're accepted into the system, ensuring they're well-formed and not designed to exploit vulnerabilities. For the current process, we are going to be using pre-specified template formats with their individual validation criteria.
Proof Validator
This keeps a track of the intent’s final success criteria set by the clients and will be used as the reference matrix to validate the final response in order to payout the solvers.
Escrow
This locks the client’s funds as escrow with the Decimal’s smart contract. This ensures that the client’s funds are never directly exposed to the Solvers or the Platform. This escrow also gives the solvers an assurance of the fund’s availability as long as they successfully fulfil their commitments. Only after a successful validation from the Proof Validator module, will the funds be released to the solver.
AI solver
AI Solver is responsible for breaking down the overall intent into granular actions. Even complex tasks can thus be handled via discrete specialized solvers.
One more functionality of the AI solver is to best match the intent liquidity request with the average inventory availability within the ecosystem. This allows for Decimal to serve even large ticket intents while maximizing the liquidity utilization for the solvers.
If the goal can’t be reached with the actions we have, we let the clients know. This also helps Decimal see what’s needed and improve for next time.
Solver Orchestration
This is master module responsible for monitoring the overall status of the intent state, its current execution state, identified solver for a particular action and to trigger the next action once the previous action is successfully completed. The final action output is returned back to the client.
RFQ Queue
For every intent action, a corresponding RFQ is issued. All participating solvers can bid for this RFQ within a set timeframe. Each of these bids will have an expiry to ensure that each bid is relevant to the latest market conditions. These bids will have the action’s expected fees and estimated execution time.
Only qualified solvers can participate in the bidding process. The qualification criteria are based on their total available (unused) staked amount. The solver can continue to update their bids continuously per their best capabilities; but there is a limit on how frequently a solver can submit revised bids to prevent spam or denial-of-service attacks.
We use cryptographic techniques to allow solvers to prove they have a valid solution without revealing the solution itself, preventing front-running or solution stealing.
Solver’s latest bid is only considered for selection, any previous bids are overridden. These bids are considered the solver’s commitment to fulfilling the action within the set parameters if selected. The action continues to stay in the RFQ queue till that action is successfully completed. This means that the solvers will continue to submit the updated bids even a solver is selected and is executing the action. This ensures that the Solver RFQ Selection module will always have the latest bid for an action at all times, and will use it to select the next best solver in line if the previous solver fails to deliver for any reason within the committed timeframe.
Solver RFQ selection
This module first checks against any malicious bids or bids intended to game the system. Next it will sort the remaining genuine bids based on either price or speed - based on the preference from the client; and chooses the right solver for the given action at the time. The default parameter is set to identify the cheapest solver.
Solver Queue
The solver once selected for an action is listed in the solver queue. The solver can now start fulfilling the request per their bid’s parameters and deliver the results.
Fault Tolerance
This module ensures the robustness of the overall process. In case any solver fails to deliver a particular action due to any reason, the solver with next competitive bid gets selected to fulfil the request. This module is also responsible for triggering the slashing process for the faulty solver for not fulfilling its commitment.
Timeouts and deadlines: There are strict timeouts for solvers to submit solutions, preventing long- running attacks or resource monopolization.
Configuration Manager
This module manages all the configuration details to manage the integrated chains, dApps and protocols and components in the Decimal ecosystem.
Debugging Service
The is a logging service to keep a track of all activities & any system errors and keep filtered reporting to the clients on the latest execution status.
Monitoring Service
This module is focused towards monitoring the external system’s performances (speed and cost for now) & liveliness status.
Analytics Dashboard
This is an internal reporting dashboard to check on the overall system performance and status. This gives us an accurate state of the solvers, intents, inventory and the overall internal system health.
Secrets Manager
Secrets manager is a special module to manage and maintain all the sensitive data that may be needed to fulfil an intent. This ensures that the solvers have access to all the needed data to fulfil their tasks. All of these private & sensitive data is handled within a TEE to prevent tampering or external exposure.
Last updated