When AI Agents Trade, Who Signs - and Who Trains Them?

AI agents are already trading - and already losing money.

At the final showcase of the Ripple–IE Blockchain, XRPL – Policy Gateway Specialization, one student team opened with recent failures: agents manipulated through prompt injection into transferring funds, with losses of $100,000 in 2024 and $250,000 earlier this year. As agents begin to transact in financial systems - particularly in crypto - their vulnerabilities are no longer theoretical.

The event marked the end of a program built around applied work within the XRP Ledger ecosystem, including an immersive period at XRPL Commons in Paris. Students were expected to develop systems that could operate under real technical, economic, and regulatory constraints.

We take a look at two projects presented at the closing session; one focused on controlling what agents can do, the other on what agents need to learn.

A co-signer that cannot be bypassed

The first-prize project, Signet, developed by Rawad Yared, Ricardo Mendez, and Vako Khvedelidze, starts from a direct assumption: AI agents cannot be trusted with financial execution.

Their system acts as a mandatory co-signer on every transaction. If the second signature is not present, the transaction does not settle. This is enforced at the protocol level using XRPL’s native multi-signature functionality.

The goal is to move compliance out of the agent and into the transaction itself. Instead of relying on prompts or monitoring systems that can be manipulated, the rules are enforced in a way the agent cannot override.

As presented, this turns compliance into something structural, not something a language model can be talked out of.

Treating the agent as untrusted

The architecture reflects that assumption.

The AI agent proposes a transaction - destination, amount, purpose - but holds only partial authority. The second half sits in a policy engine running inside a secure enclave, isolated from the agent.

The engine evaluates each transaction against fixed rules:

• amount thresholds
• destination allowlists
• asset constraints
• sanctions checks

If the transaction passes, it signs. If not, it is rejected. If it exceeds limits, it is escalated to a human.

Without that second signature, the blockchain rejects the transaction.

From decision to audit

Each decision produces a cryptographic fingerprint of the agent’s reasoning - prompt, tools, and proposed action. This is anchored on-chain, while the full reasoning is stored off-chain in encrypted form.

The result is an auditable trail: proof that a decision existed and was not altered, with the ability to reconstruct it if required.

In the context of MiCA and the AI Act - both referenced in the presentation - this becomes a way to demonstrate accountability, rather than infer it after the fact.

Signet was awarded first prize by a jury that included Lauren Weymouth, Senior Director, University Partnerships at Ripple, who noted the effective use of XRP Ledger primitives to enforce compliance at the transaction level, rather than relying on application-layer controls. 

The bottleneck before execution

A second project, Mimic, addressed a different constraint.

Where Signet assumes agents will fail at execution, Mimic starts earlier: agents lack the data needed to act reliably in the physical world.

The team - Nikoloz Kipiani, Yara Marín Fernández, Bobby Pakenham, and Rodrigo Sagastegui Martínez - positioned the problem within the growth of humanoid robotics. As production scales, the limiting factor is not hardware, but training data - specifically, large volumes of human demonstrations.

Current collection methods do not scale. Teleoperation is slow and tied to specific robots. Proprietary hardware introduces cost and fragmentation. Across approaches, data is difficult to reuse and hard to verify.

Turning everyday actions into training data

Mimic proposes a permissionless marketplace for human skill data, built on XRPL.

Instead of hiring operators, the platform opens bounties for specific tasks - cleaning a window, preparing food, handling objects. Anyone with a camera can record themselves performing the task and submit it.

The submission process reflects the constraints of working with open data:

• videos are hashed to detect exact duplicates
• similarity checks identify near-duplicates or reused content
• human reviewers assess quality before acceptance

Once approved, contributors are paid in RLUSD. This avoids volatility and lowers the barrier to participation—users are not expected to engage with crypto markets, only to receive predictable compensation.

The system turns routine actions into training data without requiring specialized equipment or retraining contributors.

Provenance and reuse

Each accepted submission is registered on-chain. The hash, timestamp, and ownership are recorded, while the video itself remains off-chain.

This allows datasets to be reused and resold, with contributors receiving royalties through XRPL. The emphasis is not only on scale, but on provenance - knowing where data comes from and how it is used.

That traceability aligns with emerging regulatory requirements around training data transparency, particularly under the AI Act.

During the final presentations, Lauren Weymouth pointed to the “clever use of XRP Ledger features” across projects, and in Mimic’s case highlighted the structure of its business model—combining marketplace commissions, dataset reuse, and resale—as well as the clarity of its go-to-market approach. The system was framed not just as a technical solution, but as one that could operate within existing infrastructure.

Two constraints, one system

The two projects approach different parts of the same problem.

• Signet addresses execution: preventing agents from acting outside defined constraints
• Mimic addresses training: supplying the data agents need to act in the first place

Both rely on XRPL primitives - multi-signature, escrow, NFTs - as mechanisms to enforce rules such as who can act, under what conditions, and with what traceability.

Both projects recombine existing components to address specific failure modes—uncontrolled execution in one case, unscalable data in the other.

As agents move from tools to actors, two limitations become clearer. They cannot be fully trusted. And they do not yet have enough data to generalize reliably.

The projects presented at the Gateway Specialization final do not attempt to solve these at the model level. Instead, they treat them as system design problems.

One constrains behavior. The other builds the pipeline that enables it. Together, they suggest a shift in where responsibility sits: not inside the model, but in the systems that surround it.