AlphaArc

1/ Update #3: Swarms, Protocols, and Autonomy Welcome to the third post in our update series. In Update #1, we walked through the changes we made to our indexing infrastructure — how we’re storing and structuring data to support more advanced APIs. Update #2 focused on what didn’t work: some painful lessons around agent autonomy, scores, prompts and even fundamental changes in system design & creating UX for agents. Today, we're looking forward. This update is all about how we’re turning those insights into the next generation of AlphaArc. We are looking into the fast changing AI landscape and how emerging patterns apply to AI powered trading bots. Specifically, we’ll break down: - Why the prompt "trade for me" is fundamentally unworkable. - How we can deconstruct complex tasks into agent-manageable components. - How a swarm of agents can collaborate effectively through protocol-based communication to help us trade more efficiently. - Explain the changes to our products and the way we build agents.

9/ From Lightweight to Bottlenecks Our early setup at AlphaArc was intentionally simple: agent configs in flat files, a shared TypeScript + LangChain runtime, and serverless execution via Lambda triggered by database events. This let us move fast and ship deployments while others were still working out infra pipelines. But the limits especially for swarms showed up quickly: Cold starts and runtime constraints. More importantly, we hit architectural walls: No shared memory, so agents couldn't build long-term context. They would "forget" between runs. No structured coordination, making multi-agent systems hard. We are changing this now by creating a better runtime that can manage the agent lifecycle of multiple agents built with different software and framework stacks. The goal is to run agents built with Rust, Python or any other language. Allowing us to leverage frameworks and use for example our experimental Arc runtime: github.com/AlphaArc4k/Alp… 9/9 END

7/ Agents Need an Environment This might sound like a technical detail, but it’s foundational: agents need a structured environment to operate in. There are promising ideas — like agents running in Trusted Execution Environments (TEEs) — but in practice, many teams skip the basics: What memory or state does the agent persist across tasks? What triggers its execution? What resources can it see or act on? Getting these foundations right is critical. Without them, it’s nearly impossible to build agents that behave reliably or coordinate meaningfully. Leveraging Docker allows to make the task of spinning up 3 researchers as easy as creating 3 containers from the same image and send them instructions.

1/ Update #3: Swarms, Protocols, and Autonomy Welcome to the third post in our update series. In Update #1, we walked through the changes we made to our indexing infrastructure — how we’re storing and structuring data to support more advanced APIs. Update #2 focused on what didn’t work: some painful lessons around agent autonomy, scores, prompts and even fundamental changes in system design & creating UX for agents. Today, we're looking forward. This update is all about how we’re turning those insights into the next generation of AlphaArc. We are looking into the fast changing AI landscape and how emerging patterns apply to AI powered trading bots. Specifically, we’ll break down: - Why the prompt "trade for me" is fundamentally unworkable. - How we can deconstruct complex tasks into agent-manageable components. - How a swarm of agents can collaborate effectively through protocol-based communication to help us trade more efficiently. - Explain the changes to our products and the way we build agents.

We’re continuing the project, but evolving the current pipeline — moving away from the linear flow of chunked data → scores → Twitter agent(s) toward a more flexible architecture powered by multiple specialized agents working as a swarm. The goal is to build systems where agents don’t just report (preprocessed) data, but actively assist in the trading process.

1/ Update #2: AlphaStudio, Trading Agents, Hard Lessons, and What Comes Next Welcome to the second post in our update series, where we dive deep into the systems we’re building — and the ones we’re leaving behind. We’ll be radically honest about what worked, what didn’t, and how our thinking has evolved as we continue to build AI-native tools for trading. This post is packed with insights and lessons learned and therefore a bit longer—our hope is that it serves as a valuable resource not just for us, but for other projects as well. We welcome others to learn from our mistakes, build on our progress, and collaborate with us moving forward.

7/ Where We’re Going Next We’re not abandoning what we’ve built; instead, we’re thinking bigger and embracing the need for significant changes. AlphaStudio will remain a valuable tool, and we’ll continue maintaining the open-source repository. However, given how quickly the software landscape is evolving, we’ve realized we need to challenge some of the assumptions we held just a few weeks ago. We’re at a unique moment in time. The tools we have are still in their early stages, but they’re rapidly improving, and the potential ahead is massive. Our next step is to refine how agents can collaborate in swarms, enabling more sophisticated, autonomous trading systems. These advancements will allow us to create self-improving systems, reducing their dependence on static scores and human intervention as they evolve. The work we’re doing now is still in development, and while it's not yet public, we’re committed to sharing more once we feel it’s ready to make an impact. In our next post, we’ll already dive deeper into how agents can support and improve trading strategies and what the future holds for fully autonomous trading systems. We’re excited about the path ahead and the potential for what we’re building. Stay tuned for more updates! 7/7 END

6/ 3) We need to design UX for agents — not just for humans AlphaStudio was designed as an IDE for humans, with input fields, buttons, and a layout that visually organizes information. One of the biggest hurdles we encountered was defining the SQL queries, and we always thought, “Give it a couple more releases, and LLMs could handle that part of the process.” The config file was create intentionally as a single document: easy to parse, understand or generate by an LLM. We thought we were future-proof. As we continued developing AlphaStudio, we saw a massive shift in how we viewed software design. The focus was no longer on optimizing for human interaction but on making the experience seamless for the AI at the core. New tools like Cursor are a perfect example of this change. The majority of interaction now happens through chat interfaces, where we no longer need to click buttons. When we "vibe code", we might not even touch the keyboard — we simply use spoken natural language to define our intent. This realization caught us a bit off guard. AlphaStudio was always meant to be an intermediate step, a way to flesh out the core functionality before transitioning to a chat-based interface. The vision for 2.0 was a prompt-driven tool: “Build me an agent that trades breakouts based on RSI and Twitter sentiment. Here’s my API key.” However, as we realized the profound paradigm shift in how AI is interacting with software and MCP servers, we also recognized that by the time we fine-tuned some aspects of AlphaStudio, they might already be outdated. We think people won’t build agents by writing code or dragging blocks — they’ll describe intent.

4/ Key Takeaways: We’re changing our data model We’re building a better backtesting engine. Historical data API access is suspended. Our backend is being restructured for scale and sustainability. We’ve also been making major updates to AlphaStudio, based on everything we've learned — more on that in an upcoming post. We are in discussions how to make data available via MCP. Stay tuned. 4/4 END

3/ Next Steps: Arctis 2.0, Carbon Integration & the Future of Data Access We’ve made major improvements to Arctis, our data parsing engine, and recently integrated it with the Carbon framework by @SevenLabs_ — which is amazing and turned out to be an excellent drop-in replacement for several of our custom parsers and decoders. 🔥 If you're curious, you can check out our unit tests — Arctis 2.0 now correctly handles even complex multi-token, multi-pool swaps: 👉 #issuecomment-2620187460" target="_blank" rel="nofollow noopener">github.com/AlphaArc4k/arc… Over the past few weeks, we’ve been preparing the indexer to leverage this new parsing logic. Here's what we're currently doing: - We're re-indexing all raw blocks using Arctis 2.0 - These will be compressed into weekly(!) data chunks - After processing, raw block data will be discarded to eliminate redundant, uncompressed storage. Arctis 2.0 is currently covering north of 75% of all on-chain activity(!!) eliminating the need to redundantly store raw historical data. This new format has its own tradeoffs: ✅ More efficient for backtesting, cheaper to store ⚠️ More expensive to expose on-demand as user-facing API Importantly, paper trading will remain unaffected by this change. Looking ahead, we’re moving toward a new hybrid approach: - Real-time data <5m for active strategies - Snapshot-based historical data for fast, large-scale backtesting of the most promising strategies, score development and other initiatives We’re phasing out the in-between model of exposing historical data via API — it’s been abused by some users and isn’t sustainable to maintain at scale in the current market. Once re-indexing and restructuring are complete, we’ll begin exploring how to offer a dedicated paid backtesting service. We've already had promising conversations with other teams about building a MCP service powered by our data infrastructure — for all types of agents, in collaboration with some amazing projects. More on that in a future post.

1/ AlphaArc Update: Indexer, Historical Data & API Hey everyone, Over the next few days, we’ll be sharing a series of updates covering our thoughts on the market, the intersection of AI and crypto, trading activity, and the current state of the AlphaArc project. This is the first in that series — focused on changes to our indexer, historical data, and API.