The problem Oronyx solves

AI agents are increasingly being trusted to act autonomously with real money — trading, rebalancing, staking — but almost every "agentic finance" demo today relies on the same weak guarantee: a system prompt or app-level setting telling the agent what it's "supposed" to do. If the agent misbehaves, is prompt-injected, or the backend is compromised, there is nothing structurally stopping it from moving funds outside the user's intent.

Oronyx solves this by moving policy enforcement on-chain. When a user sets up an agent, they describe their rules in plain language — spending limits, which actions are allowed, which targets are whitelisted, how risk-averse the agent should be. This gets compiled into a Move capability object on Sui that structurally gates every action the agent can take. The agent's backend never holds a blank check — it holds a scoped, revocable, on-chain-enforced permission slip.

Concretely, this means:

• An agent literally cannot exceed a spending limit, act on a non-whitelisted address, or act past its expiry — not because it was told not to, but because the smart contract will abort the transaction.
• Anything above the user's risk threshold isn't silently auto-executed — it's parked on-chain for the user to explicitly approve or reject.
• The user can edit policy live (tighten a limit, revoke a target, deactivate the agent entirely) at any time, independent of whether the backend is online, trustworthy, or even compromised.

This is useful for anyone who wants the convenience of an autonomous financial agent — a rebalancer, a DCA bot, a staking optimizer — without having to fully trust the software running it.

Challenges we ran into

Cetus testnet had no usable liquidity. We built a full Programmable Transaction Block integration against Cetus's SDK, expecting to demo a real swap. Systematic testing — discovering real pools, correcting swap direction to match which side of the pool SUI actually sat on, verifying coin decimals — eventually surfaced Cetus's own zero-output abort (code 18) across every SUI-paired testnet pool we could find: the price ratios were too skewed to produce a meaningful output at reasonable test amounts. Rather than keep chasing a moving target, we built our own fixed-rate mock DEX as the demo's primary swap path, and kept the real Cetus integration fully implemented and reachable — a deliberate reliability decision, not an abandoned feature.

Getting the trust model right took real iteration. Our first design had the agent's capability object owned by the user's wallet address — which turned out to be a fundamental blocker: an address-owned object can only be used by a transaction that address itself signs, which would mean the user co-signing every single agent action, defeating the point of automation. We restructured to shared objects with explicit owner/operator fields checked in the contract logic instead, which is what actually enables autonomous execution while keeping the user as the sole authority over policy changes and approvals.

Cetus's SDK doesn't compose the way we assumed. We initially planned to chain our policy-check function's released funds directly into a Cetus swap call within one atomic transaction. Checking the SDK's actual installed type definitions (rather than trusting the docs) revealed it always builds its own transaction internally and selects its own input coins — there's no way to hand it an existing transaction or a specific coin. We resolved this by scoping the two-step, non-atomic pattern specifically to Cetus, while keeping every other action type (transfer, stake, mock swap) atomic and funds-never-leave-custody by default — this also became one of our core architectural principles going forward.

Noodles.fi temporarily suspended on-chain API access for retail We planned to use Noodles.fi API to poll market data in Sui Network, but in unfortunate turn of events, Noodles announced that they are temporarily suspending access to their API dashboard within the time frame of this hackathon. We instead opted to use market data from DeepBook.

Reliably fine-tuning the agent decision-making to get desired action outcomes The agent decision-making takes in real market trends data, agent cap, current vault balance and recent activity. Each variable input has to be carefully filtered to ensure predictable outcome for live demo simulation. For example, a long history of failed actions reinforces the agent's decision to withhold from making further actions, requiring clean up of activity logs or filtering redundant activities.