
YourTurn 2.0
AI recovers value from unused bookings—within limits you set, without taking wallet control.
Demo
About
YourTurn lets people delegate the recovery of bookings they can no longer use to an AI agent — without giving that agent broad control of their wallet, account or other bookings. The problem is simple: plans change. You book a yoga class, appointment, sports session, event or another time-based service, then something comes up. In most systems your options are poor: lose the booking, navigate a cancellation policy, manually find someone to take it, or spend time negotiating with the provider. Even where resale or transfer is possible, the customer normally has to manage every step themselves. YourTurn turns that into a delegated task. A customer selects one specific booking and gives an agent a narrowly defined **Recovery Mandate**. The customer decides what the agent is allowed to do, the minimum value they are willing to recover, how long the permission lasts and which actions are explicitly forbidden. The service provider's own rules remain binding as a separate layer. The goal is not to give an AI agent a wallet and hope it behaves. The goal is to give it one job, with boundaries that it cannot silently widen. ## A simple example In our main journey, Maya holds a Friday Yoga booking that she can no longer attend. She asks YourTurn to recover the booking, but only under specific conditions: **recover this booking for me, but never for less than 40 USDC net.** That authority applies only to this booking, only to the permitted recovery action and only until the mandate expires. Studio A, the service provider, still controls its own rules independently. Maya cannot authorize the agent to do something the provider does not allow. From there, the agent can handle the repetitive work: inspect the booking, evaluate the current recovery conditions and determine whether an available opportunity fits both Maya's mandate and the provider's policy. Bob first offers **32 USDC**. YourTurn rejects it automatically because it is below Maya's minimum. No payment is attempted and the agent cannot decide that "32 is close enough." It must either find a compliant alternative or stop and ask for a new human decision. Bob then offers **45 USDC gross**. Before the recovery can proceed, YourTurn re-checks Maya's current mandate, Studio A's current provider rules, Bob's eligibility and payment authorization, and the current booking state. In our demo configuration, Studio A receives a 10% provider royalty. That means the 45 USDC offer results in: **40.5 USDC to Maya** **4.5 USDC to Studio A** Maya's minimum applies to what she actually receives, not merely the headline amount Bob pays. Because Maya nets 40.5 USDC, the offer clears her 40 USDC floor. Bob becomes the new booking holder, sees the booking in **My Bookings** and can check in. Studio A sees Bob as the current holder and can fulfil the session normally. Maya retains the recovery receipt even as the booking lifecycle continues. That connected Maya → Bob → Studio A journey is important to us because recovery should not be a disconnected crypto action. It has to make sense as a real product before, during and after the transfer. ## The core idea **AI automation should not mean unlimited AI authority.** The agent can search, reason and act, but only inside a permission envelope created by the human and constrained by the provider. A wrong agent, wrong booking, expired mandate, replayed request, prohibited action, changed provider policy, invalid payment state or recovery below the customer's minimum should stop the operation rather than silently broadening what the agent is allowed to do. The blockchain and security infrastructure should also remain largely invisible to the person using the product. Maya should be able to think: > "Recover my Friday Yoga booking for at least 40 USDC." She should not need to think about NFT allowances, transaction payers, typed-data signatures, nonce stores, agent protocols or settlement reconciliation. Those technologies exist underneath the experience because they make the boundaries around the agent stronger and the resulting state more independently verifiable. ## Three trust layers, one bounded action Making delegated recovery safe led us to separate three questions that are often collapsed into one: **Ledger defines what the human allows.** **World proves who is asking to act.** **Hedera provides the booking-right, settlement and verifiable-state layer.** None of those layers replaces the others. ### Ledger — what did the human authorize? Ledger protects the point where Maya grants or changes the agent's authority. The Recovery Mandate can bind the exact delegated agent, booking, permitted action, minimum recovery amount, settlement asset, expiry and nonce. The important idea is that hardware-backed approval can protect more than an immediate payment. It can protect the creation of a tightly scoped capability that an agent may use later. Instead of granting an AI agent general wallet access, Maya can authorize something much closer to: > "This agent may recover this booking under these conditions until this time." Ledger authorizes the mandate itself. We do not claim that Ledger signs the downstream Hedera settlement transaction. ### World AgentKit — who is actually asking? A valid mandate still leaves another problem. If Maya authorized **Agent X**, the application needs to know whether the requester arriving later is actually the human-backed registered agent that Maya intended. World AgentKit and AgentBook provide that requester-identity layer. YourTurn verifies the signed AgentKit request, resolves the agent through AgentBook and applies freshness, exact-resource and replay protections before continuing. But World deliberately does **not** decide whether the requester owns Maya's booking or has permission to recover it. A requester can be correctly verified as human-backed and still be denied. YourTurn separately checks the current Recovery Mandate, expected agent, provider policy, booking state and payment conditions. That separation is intentional: **identity verification is not the same thing as authorization.** ### Hedera — what is true about the booking and the economic result? Hedera is the booking-right and economic-state layer underneath YourTurn. Booking rights are naturally serial-specific: one customer owns one particular booking for one particular service slot. Hedera Token Service gives us a useful way to represent that right without giving a delegated agent blanket control over everything a customer owns. Hedera also gives us independently readable network state through Mirror, so booking ownership and historical transaction evidence do not need to exist only as claims inside our own database. During ETHOnline we extended the Hedera side of the system with operation-bound payment state, seller-net minimum semantics, current-state revalidation, exact transaction preparation, external-signing validation, one-shot submission protection and indexed receipt reconciliation. The result is a model where the application can reason about a narrowly authorized recovery while still treating the booking, payment conditions and resulting state as things that must be verified at the moment they matter. ## Why this is a Continuity project YourTurn existed before ETHOnline. We had already built a Hedera-native booking and resale product with tokenized booking rights, lifecycle operations, provider controls and recovery flows. An earlier version of YourTurn won Hedera's **"No Solidity Allowed — Build with Hedera SDKs"** prize at ETHGlobal Cannes 2026. ETHOnline was not about resubmitting or cosmetically polishing that system. We asked a new product question: **What happens when the customer does not want to manage recovery themselves — but also should not have to surrender control to an autonomous agent?** Answering that required a substantial new authority architecture. Before ETHOnline, recovery was something the customer directly managed and the trusted backend executed. There was no end-user delegation layer, no hardware-oriented approval boundary, no human-backed requester verification and no complete agent authority model connecting identity, mandate, provider rules, payment and current booking state. During ETHOnline we added: - booking-specific delegated authority instead of broad wallet authority; - a structured Recovery Mandate with expiry, nonce and replay protections; - current-authority revalidation rather than trusting stale approvals; - World AgentKit and AgentBook requester verification; - a Ledger device boundary for granting agent authority; - USDC-first recovery economics with seller-net minimums; - operation-bound buyer/payment state; - stronger retry and partial-failure protections; - exact Hedera transaction preparation and external-signing boundaries; - and the connected Maya → Bob → Studio A product journey. The result is not simply "YourTurn plus three sponsor integrations." The three technologies solve three different trust problems inside one delegated economic action. Remove Ledger and the human's permission boundary becomes weaker. Remove World and the application loses the human-backed requester check. Remove Hedera and booking ownership and settlement evidence fall back toward application-controlled state. Together they let us explore a model of AI delegation that is useful without requiring the user to give the agent unlimited authority. ## Beyond yoga classes We use a yoga booking because the problem is immediately understandable, but the model is broader. The same pattern could apply to: - fitness and sports sessions; - medical or wellness appointments; - event access; - restaurant and activity reservations; - lessons and workshops; - travel inventory; - coworking or facility bookings; - and other time-bound services where a customer holds something valuable they can no longer use. Across those categories, the underlying problem is similar: a person wants software to do useful economic work on their behalf without surrendering unrestricted control. That is the larger idea behind YourTurn. We want AI agents to be able to participate in real-world economic workflows while keeping the human in control of **what the agent can touch, what outcome is acceptable and when that authority ends.**
How it's made
YourTurn is built with Next.js, React and TypeScript, with Upstash Redis used for shared state, replay protection and durable recovery-operation coordination. The architecture deliberately separates three different questions: 1. What did the human authorize? — Ledger 2. Who is asking to act? — World AgentKit / AgentBook 3. What is true about the booking and settlement? — Hedera YourTurn applies the business rules that connect those layers. HEDERA Hedera is the booking-right and economic-state layer. Bookings are represented through Hedera Token Service, with Mirror Node and HashScan providing independently readable network evidence. During ETHOnline we extended the existing Hedera product with serial-scoped delegated authority so an agent can be given authority over one specific booking instead of blanket authority over a holder's assets. We built Hedera Agent Kit v4 transaction tools for preparing serial-scoped NFT allowances, revocations and delegated transfers. A particularly important design choice is AgentMode.RETURN_BYTES. Instead of letting the agent automatically sign and submit a transaction, YourTurn can prepare and retain the exact Hedera transaction bytes, then pass those bytes across an external human/signing boundary. That lets us validate the exact transaction before and after signing instead of rebuilding it later. The recovery path also binds buyer-funded USDC payment authorization, provider policy, current holder state, seller-net minimums and booking state to the same recovery operation. WORLD AGENTKIT World AgentKit is the requesting-agent identity layer. Incoming signed AgentKit requests are parsed and validated server-side. YourTurn verifies the AgentKit message and signature, resolves the requester through AgentBook, checks freshness and nonce/replay state, and adds an exact full-resource check before allowing the request to reach application authorization. We deliberately do not treat “human-backed agent” as permission to act. After World verifies the requester, YourTurn still independently checks the current Recovery Mandate, expected agent, booking, provider policy, payment authorization and requested operation. This separation became one of the most important architectural ideas in the project: identity verification and application authorization are related, but they are not the same thing. LEDGER Ledger protects the human-authorization boundary. A Recovery Mandate is represented as EIP-712 typed data. Our device path uses Ledger Device Management Kit, Ethereum Device Signer Kit and Node-HID to discover/connect the device, derive and verify the enrolled address, and present the exact structured mandate through signTypedData. The mandate binds the delegated agent, booking serial, permitted action, minimum recovery amount, expiry and nonce. Ledger signs the authorization artifact — it is not claimed to sign the Hedera HTS settlement transaction. FAIL-CLOSED COMPOSITION The three systems are composed fail closed. Wrong requester, wrong booking, stale or expired mandate, replayed nonce, changed provider policy, buyer ineligibility, failed payment or a recovery amount below Maya's minimum stops the operation instead of silently widening authority. A major engineering challenge was making retries and partial failures safe. Every recovery has an operation-bound identity and authority/payment state so refreshes, retries or an old approval cannot accidentally authorize a different recovery. Two notable integration sharp edges were worth solving: - World AgentKit 0.2.1 validates the URI host, so for a sensitive write boundary we added an exact full-resource/path check ourselves. - In our Node 22 + Node-HID Ledger runner, the DMK ESM entrypoint hit a Node resolution issue around an extensionless internal directory import, so we used the package's supported CommonJS export condition for the physical-device harness. YourTurn is a Continuity build. Before ETHOnline it already had Hedera booking NFTs, resale/recovery flows and earlier agent infrastructure. ETHOnline added the bounded delegated-authority architecture across Ledger, World and Hedera rather than simply polishing the existing product.