Inspiration

In the opening speeches, all the craze was DeFi – one of the most promising uses of cryptocurrencies. Naturally, we thought about our experiences trading, both currencies and on prediction markets, along with what we wanted to see.

We realized that the best part about betting isn’t making money – it’s doing it with friends. So, what if your friend group could be a mini hedge fund that doesn’t just trade cryptocurrencies, but can also bet on sports and events around the world?

With TARS, we made that a possibility.

What it does

When a group chat is created with TARS, a Ripple vault is built that stores everyone’s assets. As each person links their personal wallet with the group vault, the amount they deposit represents their share of the pool.

With this vault, anyone in the group can make proposals to buy or sell cryptocurrencies on Liquid or open or close positions on Polymarket. The proposals are then voted upon by the group, and if a supermajority is reached (⅔), the proposal is approved and automatically carried out. Each person’s stake in the pool represents the weight of their vote.

Although the vault isn’t just used as a way to bet or trade, it is also a liquidity pool for personal prediction markets within the group.

Anyone in the group can create a proposal to make a bet within the group, and if approved, the vault will fund the initial liquidity pools. Members can then bet for or against the event, and their stake will be locked in the vault.

Within 24 hours of the end of the event, everyone in the group votes on the outcome and TARS automatically distributes the winnings.

How we built it

The Big Picture

A group chat hedge fund that lets friend groups pool money and trade crypto and prediction markets entirely through iMessage. You text TARS (the bot), it understands plain English, and executes real trades.

Voting Allocation

The voting vault uses XRPL (XRP Ledger). When you deposit XRP, your share of the total pool equals your voting weight.

100 XRP in a 1000 XRP pool equals 10% of the vote.

This is tracked on-chain via XRPL escrow. When a trade passes, funds are locked in escrow until settlement.

If nobody has deposited yet, the system falls back to equal weight. Every person who has ever texted in the chat gets 1/n of the vote. The first person to text cannot automatically pass their own proposal — a majority of the group must approve.

The Three Backend Services

iMessage Bot
An Express server that receives LINQ webhooks. Every incoming iMessage hits /webhook, gets signature-verified using HMAC-SHA256, and is then routed appropriately.

Slash commands such as /vote yes go through a parser. Plain English messages are sent to Claude, which chooses one of seven command tools and extracts structured data.

XRPL API
A TypeScript and Express service that manages the reserve vault. It handles group creation, member registration, XRP deposit tracking, voting weight calculation, and XRPL escrow creation.

It also integrates directly with Liquid for derivatives trading. When a crypto trade vote passes, the service automatically places the corresponding perpetual order on Liquid.

Polymarket Backend
A TypeScript and Express service with a Postgres database using Prisma ORM.

It manages Polygon EVM wallets with encrypted private keys stored in the database, searches Polymarket markets via the Gamma API, and executes trades on the Polymarket CLOB using EIP-712 signed orders.

Each group chat receives its own Polygon wallet.

Key Design Decisions

Proposals are local while execution is external. Trade proposals and votes are stored in a simple JSON file (store.json) within the iMessage bot. No database is required for the voting flow.

XRPL is only consulted to determine voting weights, not to manage proposal lifecycles.

Polymarket and Liquid are only called when execution actually happens.

We also designed a dual vault system with two separate pools of funds:

  • Voting Vault (XRPL) — XRP deposited here determines voting power.
  • Trading Vault (Polygon USDC) — This vault funds the Polymarket trades.

Claude is used as the command parser. Instead of requiring rigid commands, any plain English message addressed to “tars” is sent to Claude with seven tool definitions.

Claude determines the correct command and extracts structured fields. This means that something like:

"yo tars fade trump, put 50 on him losing"

works exactly the same as a structured command like:

/propose_trade

Challenges We Ran Into

One of the biggest challenges we encountered was bridging across multiple financial ecosystems that all use different native currencies and architectures. Our system integrates with the XRP Ledger ecosystem via Ripple, the Polymarket prediction market built on Polygon, and Liquid.

Each platform has its own wallet standards, transaction models, and liquidity mechanics. Designing a unified backend that could interact with all three environments—while still presenting a simple experience to the user—required significant architectural work.

In practice, this meant building abstraction layers that normalize transactions, balances, and market interactions across completely different blockchain infrastructures.

Another major challenge came from our decision to build the interface around iMessage. Most trading bots and fintech automation tools live inside developer-friendly environments such as Slack, Telegram, or Discord where APIs and bot frameworks are mature and well documented.

iMessage, however, is not designed to function as a programmable command interface. We chose it deliberately because we wanted TARS to feel social and native to everyday conversations, but this required additional infrastructure to capture, parse, and process messages reliably.

Closely related to this was the difficulty of converting natural language messages into structured commands. Users might say something like “bet $20 that NVIDIA beats earnings” or “buy YES shares in the election market.”

Translating these free-form inputs into deterministic actions required building an AI-driven interpretation layer that maps conversational text into trading commands, wallet interactions, and prediction market operations.

We also spent significant time working through the mathematical mechanics behind personalized prediction markets. Traditional platforms rely on large liquidity providers and market makers, but our system allows small groups of users to spin up their own markets directly inside a chat.

This required designing a model for initial liquidity pools, share pricing, and payout calculations that remains fair even with a small number of participants.

Finally, wallet management across platforms proved to be another complex challenge. Each user might interact with markets on Ripple, Polygon, and Liquid simultaneously.

This meant securely managing multiple wallet types, routing transactions to the correct networks, and maintaining accurate balances while hiding this complexity from the end user.

Accomplishments We’re Proud Of

Despite these challenges, we successfully built a system where the entire trading and prediction pipeline runs directly through iMessage. Users can create markets, place trades, and view outcomes entirely within their existing conversations.

This aligns with our broader vision for TARS: turning financial decision-making into a social experience embedded inside everyday communication.

Another major milestone was enabling three different types of activity within a single system:

  • Trading crypto assets
  • Betting on existing Polymarket markets
  • Creating custom prediction markets within group chats

Integrating these workflows required flexible infrastructure capable of handling multiple market types without forcing users to switch platforms.

We are also particularly proud of the personalized prediction market system, which includes a mechanism for initial liquidity pools. This allows small groups of friends, teams, or communities to create functioning markets without relying on external market makers.

Another accomplishment was figuring out how to execute Polymarket trades from within the United States while navigating regional infrastructure constraints.

Finally, we built three separate APIs that act as the connective tissue of the system. These APIs coordinate interactions between Linq, Polymarket, Ripple infrastructure, and Liquid so commands and transactions can move seamlessly across platforms.

What We Learned

Throughout this project, we gained hands-on experience working with infrastructure on the XRP Ledger, particularly through the XLS-65 Single Asset Vault mechanism.

These vaults provide a framework for managing pooled assets and automated financial operations, which became a key building block for liquidity and shared trading pools within our system.

We also learned how to interact with the Polymarket CLOB API, which powers trading on Polymarket’s decentralized order book running on Polygon.

Working directly with a decentralized limit order book introduced challenges around order placement, settlement, and market resolution.

Another area of learning involved designing personalized prediction markets. We had to carefully think through how markets behave when liquidity is small, how odds should initially be priced, and how payouts should be distributed fairly once outcomes resolve.

Finally, we developed a deeper understanding of Ripple’s architecture and ecosystem, including how its ledger, asset structures, and financial primitives can support collaborative trading and liquidity pools.

What’s Next for TARS

Moving forward, our focus is on strengthening the robustness of the system by addressing edge cases.

For example, we need to determine how the platform behaves when participants leave a group chat, how to handle malicious actors attempting to manipulate personalized markets, and how to ensure fair outcomes when participation changes over time.

We also plan to build a dedicated user interface and onboarding flow. While the iMessage interface demonstrates the power of conversational finance, a companion UI will make it easier for users to view balances, understand markets, and join the ecosystem.

Ultimately, our goal is to continue evolving TARS into a platform where financial coordination, prediction markets, and trading become native parts of social conversation.

Built With

Share this project:

Updates