goat-sdk/goat: an archived agentic finance toolkit for TypeScript and Python agents

The problem GOAT solves: giving an agent a wallet and a set of chain actions

An agent that only calls language models cannot pay for anything. To move money it needs a key, a chain client, a way to sign, and a set of typed actions the model can call. Wiring that by hand means writing the same wallet plumbing for every chain and every framework, and rewriting it when the agent framework changes.

GOAT is aimed at that gap. The README describes it as an "agentic finance toolkit" and lists what an agent should be able to do with it: send and receive payments, purchase physical and digital goods, earn yield, bet on prediction markets, buy crypto assets, tokenize assets and pull financial insights. The intended audience is a developer who already has an agent loop (Vercel AI, Langchain, LlamaIndex, Mastra, Eliza, an MCP server, or a REST call to a model) and wants to attach financial actions to it without building a chain abstraction from scratch.

The design choice that separates it from a monolithic SDK is stated plainly: the core stays minimal and you install only the tools you need. That matters because a toolkit that ships every chain integration in one package drags in dependencies you will never call. Here the trade-off is the opposite one: you assemble the pieces yourself, so the amount of code you own goes up.

How the plugin, wallet and chain layers fit together

The repository is a monorepo with two top-level language trees, typescript/ and python/, plus a root package.json that is marked private and only carries build tooling. The root scripts are thin: build runs pnpm turbo build, and prepare runs husky. Engines pin Node to >=20.12.2 and the packageManager field pins pnpm@9.14.2, with npm and yarn explicitly rejected through the "please-use-pnpm" placeholder in the engines block. That is a real constraint, not a suggestion: the workspace expects pnpm.

The README describes the flow in four steps: give the agent a wallet, let it transact anywhere, use more than 200 tools, and run it with any agent framework. The supported surface is organised along those axes. Chains and wallets are separate from tools, and both are separate from the framework adapter. Examples are filed the same way, under by-use-case, by-framework and by-wallet directories, so the same use case (send and receive tokens, for instance) has a separate example for EVM, Solana, Chromia, Cosmos, Fuel, Radix and Zetrix.

Because the core is deliberately small, extension is the intended path when something is missing. The README names four things you can add yourself: a plugin, a chain, a wallet, and an agent framework. For a team, that is the real architecture question. You are not buying a finished product with a support contract; you are adopting an interface and a set of adapters that you may have to extend.

Installing GOAT and running a first TypeScript example

The README does not print a single install command. It points at example directories instead, and the root package.json tells you which package manager the workspace expects. Start by cloning the repository and installing at the root with pnpm, because the engines field rejects npm and yarn.

git clone https://github.com/goat-sdk/goat.git
cd goat
pnpm install
pnpm turbo build

The build script is pnpm turbo build, so turbo drives the workspace build across the typescript and python trees. If the install fails on an engine check, that is the pnpm@9.14.2 and Node >=20.12.2 pin doing its job rather than a broken repository.

From there the README's route is to pick an example that matches your chain, wallet and framework. Sending and receiving tokens on EVM lives under typescript/examples/by-use-case/evm-send-and-receive-tokens, and the framework adapters are filed separately, for example typescript/examples/by-framework/vercel-ai and typescript/examples/by-framework/model-context-protocol. The README notes that an example written for one chain, wallet and framework can be adapted to another, but it does not document the adaptation steps, so expect to read the adapter source.

cd typescript/examples/by-use-case/evm-send-and-receive-tokens
pnpm install

What you should see after that is a runnable example that constructs a wallet, registers the tools for the chain, and passes them to the agent framework. The README does not list the environment variables or key material each example needs, so check the example's own files before running it. The npm package name visible in the README badge is @goat-sdk/core, and the Python side publishes to PyPI as goat-sdk.

Where GOAT stops being the right tool

The first limitation is the one printed at the top of the README: the repository is a read-only historical snapshot, no longer actively maintained, and no issues, pull requests or updates will be accepted. The last push was on 2026-07-02. There are no releases retrieved for it. For a library that signs transactions against live chains, that is the deciding fact, because chain clients, RPC endpoints and contract addresses change on their own schedule, not the toolkit's.

The second limitation is the maintenance model itself. With more than 200 integrations across many chains, the surface is far larger than any single team can verify. The README does not document a versioning or deprecation policy for individual plugins, and it does not state which integrations are tested. If you depend on one chain adapter, you are depending on code whose test status you have to establish yourself.

The third is scope. GOAT is about agentic finance: payments, trading, tokenization, yield. If your agent needs to read a database, call an internal API or drive a browser, this toolkit adds a wallet abstraction you do not need. The minimal core cuts both ways; you still take on the chain and wallet concepts to get anything useful.

Finally, there is the security question the README does not answer. It describes giving an agent a wallet and letting it transact, and it lists custodial wallet examples alongside smart wallets, but it does not document key storage, spend limits or approval flows. Those are your responsibility, and the archived state means no upstream fix is coming.

How GOAT differs from a single-framework tool library

The closest comparison is a framework-native tool library, such as the tool definitions that ship with an agent framework or an MCP server that exposes a fixed set of actions. Those are simpler to start with: you install one package, register the tools, and the framework handles the calling convention. The cost is that the tools are tied to that framework, and the finance side is usually absent, so you still write the wallet and chain code.

GOAT inverts that. The framework is the swappable part: the README lists Vercel AI, Langchain, LlamaIndex, MCP, Mastra, Eliza, GAME and a voice agent built with ElevenLabs, plus a plain REST path through the OpenAI GPT API. The chain and tool layer is what the project owns. If you expect to move between frameworks, or to support several chains behind one agent, that separation is the reason to look at it. If you have already committed to one framework and one chain, a framework-native tool library plus a small wallet module will be less code.

The other difference is packaging. GOAT ships a minimal core and per-integration packages, so the dependency graph follows your choices. A bundled SDK typically gives you everything in one install and one version number. The README's claim that this keeps the toolkit lightweight is consistent with the repository layout, but it also means you manage more package versions, and with no maintainer publishing updates, you manage them permanently.

Licence and the real cost of an archived dependency

GOAT is MIT licensed, stated in both the README and the root package.json. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum, and it is what makes an archived repository usable at all: you can fork it, keep your changes private or publish them, and ship it inside a product.

What MIT does not give you is anyone to fix things. The README's warning is explicit that no issues or pull requests will be accepted. Practically, that means the upgrade cost is not a version bump; it is the cost of owning the fork. If a chain you depend on changes an RPC method or a contract interface, you patch your copy. If a transitive dependency gets a security advisory, you patch your copy. Budget for that before adopting, and check whether the packages you actually install are still resolvable at the versions the lockfiles pin.

The repository carries both package-lock.json and pnpm-lock.yaml at the root, while the root package.json tells npm and yarn users to use pnpm. Treat the pnpm lockfile as the one the workspace is built around.

Editorial conclusion

GOAT is worth reading if you are building an agent that has to hold a wallet and call chain-specific actions, and you want a plugin interface you can copy into your own codebase. It is the wrong choice if you need a dependency with a maintainer behind it, because the repository is a read-only snapshot: no issues, no pull requests, no updates. Before you commit to it, clone it, run the pnpm turbo build at the root, and open one of the examples under typescript/examples/by-use-case to confirm the chain, wallet and framework combination you need still compiles against the package versions you have.

Frequently asked questions

Official sources

1. goat-sdk/goat on GitHub
2. Issues
3. License: MIT
4. README