The problem Kyros System solves

Kyros helps crypto-native teams protect upcoming contractor and supplier payment
budgets from treasury volatility.

A small Web3 agency may hold ETH or BTC, but still need to pay $10,000 in USDC over
the next month. If the treasury asset falls before payday, the team may need to sell
more crypto than expected, delay payments, or reduce runway.

Kyros turns this into a clear operational flow:

• Keep the status pending until the treasury wallet approves the final protection
  order.

• Prepare recipient USDC payouts through Sui.

Kyros is not designed as a trading dashboard. It makes options understandable as
payment certainty: “Can we still pay our team if crypto drops?”

Its target customers are small crypto-native agencies, DAO operations teams, and
protocol teams with recurring contractor payments and volatile crypto treasuries.

Challenges we ran into

The hardest challenge was making a cross-chain flow feel simple without pretending
that complex actions had already happened.

We separated Base-side protection from Sui-side payouts and made every status
explicit. Kyros never labels protection as active until a wallet confirms the final
Thetanuts order.

Wallet handling was another hurdle. Multiple browser wallets could be detected, and
automatic selection created confusion. We replaced this with an explicit Sui Testnet
wallet selector in the navigation, then display the connected wallet’s shortened
address after connection.

We also encountered testnet token visibility differences between wallet interfaces
and blockchain explorers. Instead of assuming a displayed wallet balance was
available everywhere, we built the payout flow around the connected wallet’s on-
chain account and clear testnet-only messaging.