# GOAT: an agentic finance toolkit, now a read-only snapshot > GOAT was built to make an agent an economic actor: give it a wallet, let it transact anywhere, hand it more than 200 tools, and run it inside whatever agent framework you already use, across TypeScript and Python. The complication is that the repository now opens by declaring itself a read-only historical snapshot that accepts no issues, pull requests or updates, so it is worth reading as a reference implementation rather than adopting as a dependency. **goat-sdk/goat** — [Archived] Read-only historical snapshot. No issues, PRs, or updates. Use as-is. - Repository: https://github.com/goat-sdk/goat - Stars: 1,008 · Forks: 303 - Language: TypeScript - License: MIT - Published: 2026-09-15 · Updated: 2026-09-15 · Language: en - Canonical page: https://hysenlabs.com/projects/goat-sdk-goat ## The README opens with an archive notice The first thing in the file is a warning block, and it changes how everything after it should be read. It states that the repository is a read-only historical snapshot, that it will no longer be worked on, and that no issues, pull requests or updates will be accepted, with the instruction to use it as-is. That is more than a boilerplate line, because the project has real weight behind it: the repository sits over a thousand stars and three hundred forks, and the open issue count is in the dozens. A fork that needs a fix has nowhere to send it. The dates line up with the notice. The last push to `main` was 2026-07-02, and the repository has no GitHub releases at all, so there is no tag to pin and no version to cite beyond whatever you find in a lockfile. So the practical reading is that GOAT is a reference implementation. Its chain adapters, wallet integrations and framework examples are still worth studying, and the code still runs against public chains, but you are choosing to maintain whatever you build on top of it. ## Two SDKs in one repository, and two lockfiles The top level is small: `.editorconfig`, `.github/`, `.gitignore`, `.husky/`, `AUTHORS`, `CONTRIBUTING.md`, `LICENSE`, `README.md`, `goat.code-workspace`, `package-lock.json`, `package.json`, `pnpm-lock.yaml`, and then the two SDK trees, `python/` and `typescript/`. The `goat.code-workspace` file is a VS Code workspace definition, which tells you the repository is meant to be opened with both SDKs at once rather than one at a time. Git hooks are wired through Husky, with `prepare` set to run it, so the install step sets up the commit checks for you. The lockfile situation is the odd part. Both `package-lock.json` and `pnpm-lock.yaml` are committed, even though the manifest's engines field sets `npm` and `yarn` to the string `please-use-pnpm` and requires pnpm 9 or newer. The build script is `pnpm turbo build`, and `packageManager` pins `pnpm@9.14.2`, with Node 20.12.2 or newer required. So the npm lockfile is a leftover from before the pnpm requirement, and an install with npm will be refused by the engines field anyway. ## The manifest still points at crossmint/goat The root manifest describes a different repository than the one it lives in. It is private, named `goat-repo`, versioned `0.1.0`, MIT licensed, with keywords `ai`, `agents` and `web3`. Its `homepage`, `repository` and `bugs` fields all point at `github.com/crossmint/goat`, while the repository itself is `goat-sdk/goat`. That is a trace of the project's history rather than a mistake: the README credits Crossmint as the sponsor, and the repository has evidently been moved or transferred from the Crossmint organisation to `goat-sdk` without updating those three fields. It matters in two practical ways. A clone following the `repository` field lands somewhere other than where the code now lives, and the `0.1.0` version in a private root manifest says nothing about the version of the SDK anyone installs, since the published packages are separate artifacts under the `typescript/` and `python/` trees. So if you are pinning a version, read the package manifest of the SDK you actually depend on rather than the workspace root. ## Give it a wallet, 200 tools, and any framework The pitch is four steps: give your agent a wallet, allow it to transact anywhere, use more than 200 tools, and use it with any agent framework of your choice. The infrastructure underneath is named directly: blockchains, cryptocurrencies such as stablecoins, and wallets, used to let agents become economic actors rather than text generators. The capabilities listed are concrete. An agent can send and receive payments, purchase physical and digital goods and services, engage in investment strategies including earning yield, betting on prediction markets and purchasing crypto assets, tokenize any asset, and get financial insights. The framework-agnostic claim is the one that matters most for adoption, because it means the toolkit is not competing with your orchestration layer. The README notes that a quickstart may be written for a specific chain, wallet and framework, but that the flexibility is intended to let you adapt it to any combination. ## The chains are enumerated in the example paths The examples are organised by use case, and the chain coverage is visible in the file names rather than in a summary table. Money transmission, the send and receive payments examples, is the broadest: EVM, Solana, Chromia, Cosmos, Fuel, Radix and Zetrix each have their own example. Commerce, described as purchasing any item on Amazon, covers EVM and Solana. Investing splits into earning yield with a per-chain DeFi agent example, betting on prediction markets on EVM, and swapping tokens on both EVM and Solana. Tokenization covers minting non-fungible assets on EVM and Solana, and launching a fungible token on Solana. So the second-tier chains, Chromia, Fuel, Radix and Zetrix, appear in the payments example and not in the others, which tells you where the depth of support is uneven. The wallets get the same treatment with four named integrations: Crossmint Smart Wallets, Crossmint Custodial Wallets, Lit and Safe. Python examples are narrower, covering money transmission on EVM and Solana and investing paths such as a Solana USDC yield deposit. ## Framework adapters are where the toolkit meets your stack The TypeScript examples are also organised by framework, and the list is the best guide to what the toolkit expects of you. There is a Vercel AI example, a Langchain example, a LlamaIndex adapter that lives in the packages tree rather than in examples, a Model Context Protocol example, a voice agent built with ElevenLabs, a Mastra example, an OpenAI GPT example driven through a REST API, an Eliza Agent example, and a GAME agent example for Virtuals. Two of those entries are worth a second look. The LlamaIndex path points into `typescript/packages/adapters/llamaindex`, which means that integration is a shipped adapter rather than a demonstration, and the ElevenLabs example tells you voice is treated as a first-class input rather than an afterthought. The Eliza and GAME entries point at agent frameworks built around their own ecosystems, which is the clearest statement of the design intent: the toolkit supplies the money and the tools, and the framework supplies the conversation. None of this is a compatibility matrix, so the honest summary is that these nine integrations are demonstrated and the rest is up to you. ## Install only the tools you need, and extend four seams The stated design difference from other toolkits is that the core stays minimal and you install only the tools you need, against a catalogue of more than 200 integrations. That leaves a gap by design, and the README says what to do about it in four steps: create your own plugin, integrate a new chain, integrate a new wallet, or integrate a new agent framework. The contributing guide is the place those are documented. Those four seams are the actual extension surface of the project, and they tell you what the architecture considers variable. A wallet is a seam, a chain is a seam, a framework is a seam, and a plugin is the generic form of all three. The licensing is simple: free software under the MIT licence. Read together with the archive notice, that is the shape of the project as it stands. A large, well-organised reference implementation with four documented extension points, no longer accepting changes, and a manifest that still carries its previous organisation's URLs. ## Conclusion GOAT fits a team studying how to give an agent a wallet and a tool surface, since the per-chain and per-framework examples are the clearest published map of that problem, and the four extension seams are documented rather than folklore. It does not fit a team that intends to file issues, ship changes or depend on a maintained release, because the repository is a read-only snapshot with no releases and no accepted pull requests. Check three things before you build on it: which of the seven chains in the payments example you actually need, since support is uneven and only EVM and Solana appear in the commerce, investing and tokenization examples; whether your agent framework is one of the nine with a demonstrated adapter or one you will write yourself; and which package you would install, since the root manifest is private and versioned 0.1.0 while the real artifacts live under `typescript/` and `python/`. Fork it and own it, and use pnpm since the manifest refuses npm and yarn outright. ## FAQ ### What is GOAT? GOAT is described as an agentic finance toolkit for AI agents. The pitch is four steps: give the agent a wallet, let it transact anywhere, hand it more than 200 tools, and use it with any agent framework. Agents built on it can send and receive payments, buy physical and digital goods and services, earn yield, bet on prediction markets, buy crypto assets, tokenize assets and get financial insights. ### Is the GOAT SDK still maintained? No. The README opens with an archive notice saying the repository is a read-only historical snapshot, that no issues, pull requests or updates will be accepted, and that it should be used as-is. The last push to main was 2026-07-02 and there are no GitHub releases, so there is no tagged version to pin. ### Which chains does GOAT cover? The send and receive payments examples cover EVM, Solana, Chromia, Cosmos, Fuel, Radix and Zetrix. Commerce, investing, prediction markets and tokenization examples are narrower, covering EVM and Solana, with a Solana-only example for launching a fungible token. Python examples cover money transmission on EVM and Solana and investing paths such as a Solana USDC yield deposit. ### Which agent frameworks does GOAT support? The TypeScript examples cover Vercel AI, Langchain, LlamaIndex through an adapter package, the Model Context Protocol, a voice agent with ElevenLabs, Mastra, OpenAI GPT through a REST API, the Eliza Agent and a GAME agent on Virtuals. The README presents these as demonstrations rather than a compatibility matrix, and asks for a plugin, chain, wallet or framework integration when something is missing. ### Which wallets are wired into GOAT? Four are named with their own TypeScript quickstarts: Crossmint Smart Wallets, Crossmint Custodial Wallets, Lit and Safe. Adding another is one of the four extension points the README lists, alongside creating a plugin, integrating a chain and integrating an agent framework. ## Sources - [goat-sdk/goat on GitHub](https://github.com/goat-sdk/goat) - [Issues](https://github.com/goat-sdk/goat/issues) - [License: MIT](https://github.com/goat-sdk/goat/blob/main/LICENSE) - [README](https://github.com/goat-sdk/goat/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/goat-sdk-goat