Skip to main content
There are a few security considerations and best practices to take into account when creating a custom oracle and deploying it to the Kenshi Oracle Network. Although not required, they are highly recommended.
You should always verify the sender address of the caller to your callback function. If it is not the address of your oracle or an address you do not trust, you must revert the transaction. To view the sender address of your Kenshi Oracle, head to the Kenshi Oracle Network dashboard, select your oracle, and view the address in the "Add Credit" tab.
Gas fees stored in associated gas wallets are not insured. Kenshi protects the stored gas on a best effort basis. Addresses are derived from a common BIP39 seed, stored in a secret manager for API usage. Make sure you do not supply more gas than your oracle needs. You can always check the balance of this address in a call to your oracle endpoint and supply more gas if needed.
Kenshi caches requests as to not send an event for processing twice, and to not deliver it to your smart contract twice. In case of retries, Kenshi re-sends events to your endpoint to get fresh data (this is useful if you're checking for market data, weather data, or any data that changes frequently).
While Kenshi tries its best to prevent double-deliveries, you must make sure your smart contracts are idempotent . You can assign a unique "requestId" or "nonce" to each request on the blockchain and revert a transaction if it tries to re-deliver results for an already fulfilled request.
It is quite easy to manipulate certain types of data. For example, if you are working with market data, an attacker could put an order when the market conditions are in their favor. To prevent such attacks you can employ an averaging mechanism that best fits your use case (for example, use a one hour average or percentile of an asset's price, instead of its spot price).
Certain types of data are easily verifiable on the blockchain. For example, randomness generated by a VRF. Other types of data, such as market data, sport or weather are not so verifiable. However, it is easy to verify the sender of such data, and to make sure they are not manipulated after being generated and verified by your oracle endpoint. You can use EIP712 to sign and later verify them on the blockchain.
Choose an appropriate number for block confirmations if sensitive business logic or transfer of funds is involved. A transaction can revert, get reorganized or get cancelled before finality is reached. Learn more about finality here .