Repository: https://github.com/abba-platforms/KEN30 Version: 1.0
The KEN30 Oracle System is responsible for the secure, accurate, and verifiable submission of benchmark index values (NAV) to the KEN30 smart contract.
The oracle framework ensures that all benchmark updates are:
- derived from reliable market data
- cryptographically verified
- validated through multi-party consensus
- resistant to manipulation or unilateral control
The oracle system operates as a critical component of the KEN30 benchmark infrastructure, bridging off-chain market data and on-chain execution.
The oracle system follows a multi-operator, quorum-based architecture.
Core components include:
- data aggregation layer
- oracle signer nodes
- message signing protocol
- on-chain verification logic
Each oracle operator independently retrieves, processes, and signs benchmark data before submission.
The smart contract validates submissions based on quorum requirements and cryptographic signatures.
The oracle system uses a structured hierarchy of data sources.
Primary data is sourced directly from:
- Nairobi Securities Exchange (NSE) official price feeds
- official closing prices and authorized market data publications
These sources serve as the authoritative reference for constituent pricing.
Secondary data sources may include:
- licensed financial data providers
- regulated market data vendors
- institutional-grade data aggregators
Secondary sources are used for cross-verification and redundancy.
In cases where primary and secondary data are unavailable:
- the most recent valid traded price may be used
- fallback usage is subject to validation constraints
- fallback conditions must not exceed defined staleness thresholds
Fallback logic ensures continuity without compromising benchmark integrity.
Oracle operators are responsible for computing the Net Asset Value (NAV) of the KEN30 index.
The NAV is calculated using:
KEN30_t = ( SUM (P_i x W_i) ) / TOTAL_WEIGHT
Where:
P_i = price of constituent i
W_i = weight of constituent i
TOTAL_WEIGHT = 10,000 basis points
Each oracle independently performs this calculation prior to signing.
Oracle operators must meet defined operational and security standards.
Requirements include:
- access to reliable market data sources
- secure key management practices
- high-availability infrastructure
- ability to perform deterministic NAV calculations
- compliance with protocol-defined update schedules
Operators must maintain system integrity and ensure consistent data submission.
Oracle updates are submitted as cryptographically signed messages.
The system utilizes:
- EIP-712 typed structured data signing
This ensures:
- domain separation
- replay protection
- verifiable message integrity
Each oracle submission must include the following fields:
- nav (uint256): computed index value
- timestamp (uint256): time of calculation (EAT-aligned)
- roundId (uint256): monotonically increasing sequence identifier
- chainId (uint256): network identifier for domain separation
- indexId (string or bytes32): identifier for KEN30
- signer (address): oracle signer address
These fields are encoded into the structured message and signed off-chain.
The canonical schema for these fields is formally defined in Section 16.3.
The oracle system enforces multi-signature validation.
A predefined minimum number of oracle signatures is required for a valid update.
Example configuration:
- 3-of-5 oracle quorum
The smart contract verifies:
- authenticity of each signature
- uniqueness of signers
- quorum threshold satisfaction
Only updates meeting quorum requirements are accepted.
Oracle updates are submitted at defined intervals.
Updates may be:
- intraday (for example, hourly)
- periodic (for example, daily close)
The exact frequency is governed by protocol configuration.
All timestamps are standardized to:
- East Africa Time (EAT)
The contract enforces:
- minimum time between updates
This prevents excessive or spam submissions.
Submitted updates must pass validation checks.
Updates must fall within predefined deviation thresholds relative to the previous NAV.
Updates exceeding maximum allowed staleness are rejected.
Submissions must follow correct sequencing to prevent replay or out-of-order updates.
The oracle system includes mechanisms for handling failure scenarios.
If quorum is not met:
- update is rejected
- previous NAV remains active
If data sources are unavailable:
- fallback pricing may be used within defined limits
- extended unavailability may trigger governance action
If one or more oracle operators fail:
- system continues if quorum is still achievable
- governance may replace inactive operators
The oracle system incorporates multiple security safeguards.
Prevents single-point control over benchmark updates.
Ensures authenticity and integrity of submitted data.
Oracle configuration changes must pass through governance delay.
Oracle operators must maintain secure private key storage and rotation policies.
Oracle configuration is governed through the timelock-controlled governance system.
Governance actions include:
- adding or removing oracle operators
- modifying quorum thresholds
- updating validation parameters
All changes require:
- proposal submission
- timelock delay
- execution
The oracle system interfaces directly with the KEN30 smart contract.
The contract performs:
- signature verification
- quorum validation
- NAV update execution
- event emission
The oracle does not directly modify state without validation.
All oracle submissions are:
- recorded on-chain
- publicly verifiable
- auditable through transaction history
This ensures full transparency of benchmark updates.
The KEN30 oracle system provides a secure, verifiable, and decentralized mechanism for updating benchmark values.
Through structured data sourcing, multi-operator consensus, cryptographic validation, and governance controls, the oracle framework ensures the integrity and reliability of the KEN30 index within institutional financial environments.
Oracle operators are admitted through governance-controlled processes.
Eligibility criteria include:
- access to reliable and verifiable market data
- institutional-grade infrastructure
- secure key management practices
- deterministic NAV computation capability
Operators may be removed for:
- invalid data submission
- quorum participation failure
- key compromise
- protocol violations
The canonical message schema is defined as:
NAVUpdate { uint256 nav; uint256 timestamp; uint256 roundId; uint256 chainId; }
The fields defined in Section 6.2 must map directly to this schema.
Replay protection is enforced through:
- strictly increasing roundId
- rejection of duplicate messages
- hash tracking of processed submissions
Example configuration:
- maximum deviation: +/-5%
Out-of-range submissions are rejected.
Accepted updates are:
- final
- immutable
- forward-only
Participation may be:
- internal
- institutional
- service-based
No on-chain incentive is enforced.
Monitoring includes:
- update frequency
- deviation tracking
- quorum participation
In failure scenarios:
- updates may be paused
- last valid NAV remains active
- governance restores operations
Time reference:
- block.timestamp
Constraints:
- maximum drift
- staleness limits
End of Document