The problem RiskShield solves

Options can protect crypto holders from large losses, but most people don't know how to build an options hedge themselves.

The goal of RiskShield is simple:

Make options protection understandable for humans, while keeping financial calculations and execution under strict deterministic rules

A user may understand their goal clearly eg.

“I have a $10,000 ETH position. Protect me if ETH falls 20% or more, cover at least half of that downside, and do not spend more than $200.”

But turning that simple request into a real hedge requires understanding put options, strike prices, expiry dates and more fancy technical terms.

RiskShield makes that process easier.

The user describes the risk they care about in normal language. AI translates that request into a clear set of rules, such as:

· what asset they want to protect
· how large their position is
· how much they are willing to spend

After that, RiskShield's deterministic risk engine analyses live ETH put options from Thetanuts Finance on Base, calculates how much protection each one provides, checks the cost, rejects options that violate the user's limits, and selects a compliant hedge.

RiskShield supports two execution modes:

A) Copilot
RiskShield recommends a hedge, but the user reviews the exact transaction and approves it through MetaMask.

B) Autonomous
The user first sets strict safety limits, such as:
· Only protect ETH
· Only use USDC
· Never exceed a total spending limit

RiskShield can then monitor the market and determine whether an action is allowed under those rules.

For the hackathon, autonomous execution is kept in simulation mode so it cannot automatically spend real money. However, we separately proved that the underlying execution path works by successfully purchasing a real ETH put option through Thetanuts Finance on Base mainnet.

Challenges we ran into

1. Different options could share the same identifier

At first, we assumed that the order nonce provided by the options market uniquely identified an option. When we tested against live Thetanuts data, we discovered that this was not true. Hundreds of orders could share the same nonce, and multiple ETH put options with different strike prices could have the same one.

This created a serious risk: the system could recommend one option but later retrieve another option that shared the same nonce. We solved this by creating our own cryptographic fingerprint using all of the important details of an option, including its strike price, expiry, price and maker signature.

This ensures that the option the user approved is exactly the option the system later prepares for execution.

2. We joined the hackathon only a few days before submission, while both of us are university students preparing for exams.

This meant we had to be extremely selective about what we built. We focused on proving the most important parts properly, such as real Thetanuts market data, deterministic financial calculations, and extensive automated testing.

Some parts, such as fully automatic live trading, persistent storage and further UI/UX polish, were deliberately left for future development rather than being rushed into the hackathon version.