lino

Thrilled to share my submission for the @openservai SERV Hackathon 02, built for the @dphnAI Dolphin track: Janus + OpenServ Recovery Copilot. Janus is a recovery cockpit for Sui handovers. When an administrator transfers control to a successor, an interruption can leave both parties unsure what was approved. Janus restores signed intent from Walrus Memory, verifies live Sui Testnet state through Tatum, and produces a deterministic verdict that blocks unsafe actions. For the hackathon I added the Recovery Copilot around the real Engine.view() path. Dolphin Network interprets the normalized evidence and drafts source-linked findings. SERV Reasoning turns that interpretation, the same evidence and the deterministic verdict into a structured recovery plan. The important part is what the models cannot do. Application validation rejects unknown source IDs, fabricated addresses or digests, verdict substitution, inferred approval, fee promises and prohibited wallet actions. The copilot is advisory only. It cannot sign, submit, retry or override the deterministic verdict. Every transaction still goes through the existing wallet review and signing flow. The cockpit shows verified vs uncertain findings, expandable source evidence, review steps, open questions, provider/model metadata and a stale banner when the operation changes. What I built during the hackathon: - Allowlisted RecoveryEvidenceBundle from Engine.view() - Separate Dolphin and SERV Reasoning adapters - Strict JSON schemas plus independent application validation - Durable jobs, deduplication, rate limits, stale detection and restart recovery - Private participant-only assessments in SQLite - Recovery Copilot cockpit panel - Fixture and live Sui Testnet E2E coverage Evidence so far: 109/109 tests passing, 25/25 copilot tests, 20/20 cockpit browser fixtures, real Dolphin/SERV calls, and an isolated Sui Testnet E2E covering deployment, proposal, successor mismatch, approval, acceptance, stale detection, counter, preference, memory isolation and cancellation. The live runs also showed why validation matters: SERV once recommended wallet review on a completed handover, and Dolphin once cited a nonexistent source ID. Both were rejected; a bounded retry passed. The app is local-first and reproducible from the repo, with no hosted app claim. Existing Janus Sui/Walrus/Tatum work is clearly separated from the new OpenServ contribution. Track: Dolphin Demo: youtu.be/hfp9qpYCxWI Repo: github.com/vickman787/janus-… #SERVHackathon #OpenServ #Dolphin #Sui #Walrus

Introducing STYX — built at NEAR HACKATHON on @NEARProtocol to bring scoped spending, delivery verification, and owner-controlled payments to agent services. As agents take on more useful work, one question becomes harder to ignore: how do we let them coordinate services without giving them unrestricted control over our money? An agent completing a task and a service requesting payment are only parts of the process. Someone still needs to define the rules, check what was delivered, and decide whether that delivery deserves payment. That is the workflow we built with STYX. HOW IT WORKS The current use case is turning structured invoices into accounting CSV files. An owner prepares a job and defines its scope, spending cap, permitted service, recipient, expiry, and delivery requirements. STYX compares service quotes and connects the selected work to those rules. The delivery then goes through deterministic checks for source coverage, arithmetic, duplicates, uncertainty, and integrity. The owner can inspect the actual CSV and verification results before accepting the work. For the NEAR testnet flow, the owner reviews and signs the relevant wallet actions. Buyer-agent, provider, and verifier roles use separate identities; they do not receive the owner’s wallet keys. A verified result can proceed to owner-approved payment. Failed checks block acceptance, and a reservation can be released without paying the provider. WHAT WE HAVE WORKING • Structured JSON/CSV invoice processing. • Local parsing, with optional NEAR AI extraction behind explicit data-sharing and API-cost consent. • Owner-defined rules and spending caps. • Service quote comparison. • Downloadable CSV deliveries and source comparisons. • Separate buyer-agent, provider, verifier, and owner roles. • NEAR testnet escrow, reservation, delivery, verification, and payment flows. • Transaction reconciliation that checks final receipts and contract state after interrupted or uncertain submissions. • Completed testnet payment and reservation-release examples. WHY BUILD THIS ON NEAR? STYX uses NEAR testnet to record and enforce the agreement and settlement flow, while keeping invoice contents off-chain. The application connects the work people can inspect with the payment actions owners authorize. A wallet redirect alone is not treated as settlement: STYX reconciles the transaction and contract state before reporting confirmation. The broader idea is a reusable pattern for agent services: bounded authority, inspectable delivery evidence, and explicit owner control over payment. TRY IT WITHOUT A WALLET We also built a public sample workspace so anyone can explore the product immediately. You can load 30 fictional invoices, set a spending cap, compare quotes, inspect the generated CSV, accept a successful delivery, or try an arithmetic-failure case and release the reservation. Each visitor gets an isolated temporary workspace. Sample payments are clearly labelled simulations and do not send NEAR. Separate proof links show earlier, actual NEAR testnet transactions. WHERE WE ARE TODAY STYX is a working testnet pilot. Both configured service providers are currently STYX-operated, and the verifier runs on a trusted server. The checks establish consistency with the supplied invoice data; they do not prove invoice authenticity. Independent security review, broader user testing, and operational hardening remain ahead before commercial use. We would love feedback from NEAR builders, agent developers, and people who work with invoice processing: what evidence would you need before allowing an agent-assisted workflow to release payment? Try STYX: usestyx.xyz Public sample: usestyx.xyz/try-demo Watch the walkthrough: youtu.be/7t0hImAfEIY Explore the code: github.com/vickman787/styx Delegate the work. Inspect the evidence. Keep control of payment. #NEARHackathon #NEARProtocol #AIAgents #Web3