> For the complete documentation index, see [llms.txt](https://docs.tallyprotocol.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tallyprotocol.xyz/building-tally/the-story.md).

# The story

Tally was built in ten days for **BNB Hack: Tokenized Stocks Edition** (submissions lock 11 October 2026, 12:00 UTC). This page is the short version of how it went from an idea to a deployed product. [Challenges](/building-tally/challenges.md) has the detail.

## 30 September: what the market says

Before writing code we measured the market and analysed what the 87 projects that won 15 earlier hackathons built. Two signals stuck: evidence you can verify (receipts, proofs, audit trails) shows up in 57% of winners, and precise financial primitives beat generic "AI trader" projects. The market data told us the rest:

* There were 517 tickers across 675 tokens on BNB Chain from three issuers, and **the same stock could look 900% apart** because of share multipliers.
* The multiplier even differed by source for the same token.
* So Tally's bet: be correct about *what you get*, back it with an onchain guarantee, then be cheapest.

We shortlisted two ideas and chose Tally because every risk we could test on it had a verified answer: region, contracts holding the tokens, real routes, both issuers, and live money.

## 1 October: the facts that retired the risks

* **Region:** the Binance Web3 API refuses callers from some countries for the whole API (`40304`, sent as HTTP 200). The server has to live in an allowed country. AWS Seoul works.
* **Routes:** a quote returns one route from one vendor. The aggregator offers no comparison, so Tally has to quote each issuer's token itself.
* **A prototype guard** passed fork tests with real calldata. Then the first **live buy** reverted out of gas because the API's gas number is a placeholder. The fix (estimate, add 25%, simulate at that exact limit) became a rule.

## 2 October: three milestones in a day

1. **The engine:** pure share maths, the issuer registry, integrity grades, a signed API client with fixtures, chain access with failover, and a CLI.
2. **ShareGuard v1:** designed against the prototype's hole, tested on a mainnet fork, **deployed and verified**, with two live guarded buys: one bStock, one Ondo through the signed feed.
3. **The web trade flow:** quote, approve, swap and receipt in shares, with Privy wallets and a region gate.

## 3 to 6 October: modules, and a team

The single milestone plan became a module plan: Receipts, Portfolio and Statement, Radar and Flow, Guardian with a Telegram bot, Migrate, Pies and Autopilot (shadow mode). Work was split into work orders with explicit file ownership and handed to a team of AI coding agents under one human chief engineer. See [Building with a team of AI agents](/building-tally/multi-agent-workflow.md).

On 6 October an unattended sale ran through Binance's Agentic Wallet with no tap.

## 7 to 10 October: widening and hardening

* **ShareGuard grew** from 10 tokens to 30 through gated, evidence-checked owner batches, each confirmed onchain.
* **Migrate** shipped as a guided two-step flow after we proved the API cannot do a stock-to-stock swap.
* **Real use found real bugs:** a market-maker order that expired before it mined, a database that grew to 8 GB, a Radar page that froze the server, an RPC provider whose quota ran out, a wallet that stayed "connected" after sign-out. Each is written up in [Challenges](/building-tally/challenges.md), with the fix.
* **The domain, a Cloudflare tunnel and this documentation** went up.

## What we would do next

See the [Roadmap](/reference/roadmap.md): atomic Migrate, reliable 1-hour, 24-hour and 7-day windows, user-defined baskets, smarter suggestions, a landing page and a replayable tutorial.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.tallyprotocol.xyz/building-tally/the-story.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
