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 .
