Developers post live apps, integrations, or demos.

Ecosystem Showcase & Launches

Kyro checks a wallet before you pay a counterparty. You hand it an address or a Kyro username plus a use case. It answers allow, caution or block, with an advisory USDC limit and the evidence behind the answer. It is advisory and non-custodial. It never holds keys or funds and it cannot move or stop a transaction.


That part was already running on Arc Testnet before ETHOnline started, along with the public API, the scoring and decision models and a TypeScript SDK on npm. None of that is event work and I want to say so up front.

Here is what I actually built during the event.

A public repo for anyone who wants to put a Kyro decision in front of a payment without reading the whole API surface first. It holds the SDK source, an OpenAPI snapshot of the v1 contract, examples in curl, Python and TypeScript, an architecture outline and the docs that go with them. CI fails if the SDK and the OpenAPI snapshot drift apart, which is the bit I care about most. A devkit that quietly disagrees with the API is worse than no devkit.

To be clear about the split: the SDK itself was written before the event and published to npm on 25 August. Extracting it into a public workspace with the spec, the examples and the CI around it is the part I did during.


This was the main build. It is a small agent that pays USDC invoices on Arc Testnet through the Circle CLI, with Kyro sitting in the approval path.

Every proposed payment goes through the same seven stages. Planner, pre-screen with no network, Kyro decision read, operator policy, decision receipt, audit, executor.

The thing worth being precise about: Kyro does not stop payments. It returns a verdict, a limit, reasons and freshness. The operator policy decides what to do with that. Refuse beats hold and hold beats proceed. Anything that triggers gets printed.

The operator policy refuses before it even reads Kyro if the chain is wrong, the recipient is malformed, the agent is paying itself or the recipient is not on the task list. After the read it refuses on a block verdict. It also refuses if Kyro gave no usable answer at all. It fails closed. No answer means no payment.


Baseline answer with no committed evidence behind it. Anything over Kyro's advisory limit or the local caps. 

Duplicate inside ten minutes. The local caps in the demo default to 5 USDC per transfer and 10 per run. 

Human can approve a held payment with an interactive flag.


Dry run is the default and needs no credentials. It does everything up to the executor, then prints the exact Circle CLI command instead of running it.

Live mode runs that command, once per approved payment, with an idempotency key. Everything before the executor is identical in both modes, which is what makes the dry run useful rather than decorative.

A receipt is Kyro's immutable record of a decision at a point in time. In the gate they are off by default in dry run and on by default in live mode. One gets minted for each approved payment before any money moves.

If the receipt disagrees with the read, the payment becomes a hold. If the receipt cannot be minted at all, it becomes a refuse. No receipt, no payment.


On 9 September the gate paid one invoice live on Arc Testnet, 1.5 USDC, through a Circle agent wallet. The transaction hash and explorer link are in the repo.

That is a testnet demonstration. One invoice, on testnet, with test funds.

The planner is scripted. It proposes invoices from a task file. model driven planner is on the list and not built.

The 9 September live run predates the receipt work, so there has not been a live run with receipts on yet.

The test suite uses a stand in binary and never touches Circle or Arc.

There are no automatic retries. An unknown result means reconciling by hand on the explorer.

Circle spending policies are mainnet only, so on testnet the local caps are the only spending limit there is.

If you are building agents that move money, I would really like to hear where this design is wrong or i can improve, The refuse and hold rules are the part I am least sure about.


https://github.com/vaibhav0xq/kyro-devkit

https://ethglobal.com/showcase/kyro-vk4kd

Kyro and the Kyro-devkit is an independent project built on arc. It is not officially affiliated with the Arc or Circle team.

What I built for ETHOnline: Kyro DevKit and agent payment gate

Home

Forum

Events

Content

Courses

Collections

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

What is your job title?

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via community@arc.io if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via community@arc.io for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines