Crypto Finance AI Agents: Claude MCP & Safe Course

In this lesson, we test the first working version of a simple crypto portfolio dashboard built by Claude. The lesson walks through opening the local preview, adding a Moralis API key, adding wallet addresses, and checking that the dashboard correctly displays total portfolio value, assets across multiple chains, wallet addresses, and dollar balances.

The lesson also introduces an important limitation of the first version: the app currently stores data only in browser local storage/cache, meaning wallet information can be lost after clearing cache or relaunching the app. The next step is to improve the app by adding persistent storage, so wallets and settings are saved properly between sessions.

Key topics covered:

• Previewing a locally generated HTML app

• Adding and saving an API key

• Adding multiple wallet addresses

• Checking portfolio balances across chains

• Understanding localhost and local-only apps

• Understanding local storage vs persistent database storage

• Planning the next iteration of the dashboard

In this lesson, we start building a crypto wallet position dashboard using Claude. The lesson begins with getting a free API key for the exercise and briefly explains that free API limits may be enough for testing, but a paid plan may be needed later if the application grows and API usage becomes high.

The lesson then walks through the Claude workspace interface: checking the right pane, watching Claude read documentation, reviewing the project folder, opening the terminal, and understanding where file changes and implementation plans will appear. It also explains that prompts do not need to be highly technical: you can describe the product you want in plain language, and Claude can turn that into a concrete implementation plan.

The main focus is reviewing Claude’s proposed plan for the first version of the dashboard, including local storage, API key handling, token filtering, admin and dashboard tabs, dark UI styling, error handling, and verification steps. The lesson also shows how to approve the plan, allow edits, and optionally leave comments if you want Claude to adjust the implementation before it starts building.

Key topics covered:

• Getting a free API key for development

• Understanding API usage limits

• Navigating the Claude workspace

• Letting Claude read API documentation

• Reviewing files, terminal, diffs, and background tasks

• Writing product prompts in plain language

• Reviewing Claude’s implementation plan

• Approving edits and starting the build

• Iterating on design choices before implementation

In this lesson, we test the first working version of a crypto wallet portfolio dashboard created by Claude. The lesson shows how to open the local preview, review the generated index.html file, and understand that the app is currently running locally on localhost, meaning it only works on the user’s computer for now.

The walkthrough then covers the basic setup flow: adding a Moralis API key, saving it, adding wallet addresses, and checking that the dashboard displays portfolio data correctly. The dashboard shows total portfolio value, wallet-level balances, assets across multiple chains, and token values in dollars.

The lesson also highlights an important limitation of the first implementation: the app stores data only in browser local storage/cache. This means that wallet information may disappear after clearing cache or relaunching the app. The next improvement is to add persistent storage, so wallets and settings are saved properly and are not lost between sessions.

Key topics covered:

• Testing the first generated version of the dashboard

• Opening and reviewing a local preview

• Understanding localhost

• Adding and saving an API key

• Adding wallet addresses

• Checking wallet and portfolio balances

• Reviewing the generated index.html file

• Understanding browser local storage

• Identifying the need for persistent database storage

In this lesson, we improve the crypto portfolio dashboard by adding persistent data storage. Instead of keeping wallet information only in browser cache/local storage, Claude creates additional files, including a data.json file, so the app can store wallet data more reliably between launches.

The lesson then introduces the basic infrastructure needed to share an app with other people. It explains the difference between running an app locally on your laptop and making it available online. The key concepts covered are local project folders, dependencies, GitHub repositories, public vs private code, and deployment tools such as GitHub Pages or Vercel.

Finally, the lesson shows the updated dashboard running again: the saved wallets are already available, while the API key still needs to be added manually because it is not yet stored by the app. This becomes another improvement to address later. The lesson ends by preparing to push the project to GitHub, with deploying the app online suggested as homework.

Key topics covered:

• Adding persistent wallet storage

• Creating and using a data.json file

• Understanding local app structure and files

• Viewing and editing generated code

• Local apps vs online apps

• What GitHub is and why repositories matter

• Public vs private repositories

• Deployment basics

• GitHub Pages and Vercel

• Preparing to push an app to GitHub

In this lesson, we take the crypto wallet dashboard from a local project to a live online application. The lesson starts by showing how Claude can help with the technical deployment steps, while the user’s main responsibility is to clearly describe what they want to build, how the interface should work, and what should or should not be included.

The walkthrough covers pushing the project to GitHub by creating an initial commit and a private repository. It explains the role of the .gitignore file, especially why secrets, local files, and API keys should not be pushed to the public cloud. Instead, sensitive values like the Moralis API key should be added later as environment variables during deployment.

The lesson then shows how to deploy the GitHub repository using Vercel: importing the repository, adding environment variables, and launching the app online. After deployment, the dashboard receives a public web link that anyone can open. The lesson also highlights an important difference between local and deployed apps: local storage is not automatically copied to the online version, so the deployed app may need separate database storage to persist wallets online.

Finally, the lesson summarizes the full progress so far: creating the dashboard, improving local wallet storage, pushing the project to GitHub, deploying it on Vercel, and confirming that the live app works online. The next planned improvement is to continue building on top of the dashboard by adding a payments tab.

Key topics covered:

• Connecting Claude with GitHub

• Creating an initial commit

• Creating a private GitHub repository

• Understanding .gitignore

• Avoiding pushing API keys and secrets to GitHub

• Using environment variables

• Importing a GitHub project into Vercel

• Deploying an app online

• Testing the live public link

• Understanding local storage vs deployed app storage

• Planning the next feature: a payments tab

In this lesson, we start building the next feature on top of the crypto dashboard: an agent-assisted payments tab. The goal is to create a tool where a user can select a vendor, choose an amount and token, and initiate an on-chain transaction proposal through the dashboard.

The lesson introduces Safe as the wallet infrastructure for payments. Safe is explained as a popular multisig wallet in crypto, where multiple signers are usually required to approve a transaction. For the workshop, the setup is simplified to a 1-of-1 Safe for educational purposes. The lesson also introduces the idea of an agent proposer wallet: a separate EOA wallet whose private key can be used by the AI-assisted app to create transaction proposals for the Safe.

A key technical concept in this lesson is the .env.local file. The lesson explains why sensitive or reusable configuration values should not be hardcoded directly into the application code. Instead, values such as the Safe address, proposer private key, RPC URL, Safe API key, and Moralis API key should be stored as environment variables. This makes the app safer, easier to update, and easier to deploy later.

The walkthrough then shows how to ask Claude to create the .env.local file, add the required variables, and edit the file directly inside the Claude workspace. The lesson also touches on API quota limits when retrieving the Moralis API key and shows how to continue using a different account if the current key is exhausted.

Key topics covered:

• Adding an agent-assisted payments feature

• Designing a payments tab for the crypto dashboard

• Selecting vendor, amount, and token for payments

• Understanding Safe multisig wallets

• 1-of-1 Safe setup for educational use

• Agent proposer wallet concept

• Using private keys carefully in development

• What .env.local is

• Why environment variables matter

• Storing Safe address, RPC URL, API keys, and proposer key

• Avoiding hardcoded secrets in application code

• Creating and editing config files with Claude

In this lesson, we continue setting up the agent-assisted payments feature by creating and configuring a Safe wallet. The lesson starts by defining the environment variables needed for the payments workflow, including the Moralis API key, Safe address, Safe API key, and proposer private key.

The walkthrough then shows how to create a new Safe at app.safe.global. For the exercise, the Safe is configured on Ethereum with a simple 1-of-1 signer setup, although the lesson explains that real production wallets usually use safer multisig patterns such as 3-of-5 or 5-of-7. It also explains why 2-of-2 or 3-of-3 setups can be risky: losing access to one signer can make it impossible to execute transactions.

After creating the Safe, the lesson shows how to activate it by signing an on-chain transaction and paying a small gas fee. It then covers how to get a Safe API key from the Safe dashboard and add it to the .env.local file, so the application can interact with Safe programmatically.

The final part introduces the proposer wallet. A proposer is an address that can create transaction proposals, but cannot execute them without signer approval. This makes it suitable for an AI agent: the agent can prepare transactions, while the human signer still keeps final control. The lesson shows how to add an empty wallet as an agent proposer and explains that only Safe signers can approve this permission change.

Key topics covered:

• Defining environment variables for payments

• Creating a new Safe wallet

• Choosing networks for Safe

• Understanding multisig signer thresholds

• Why 1-of-1 is acceptable only for testing

• Why 2-of-2 or 3-of-3 setups can be risky

• Activating a Safe with an on-chain transaction

• Getting a Safe API key

• Adding Safe configuration to .env.local

• Understanding proposer wallets

• Adding an agent proposer

• Keeping final transaction approval with human signers

In this lesson, we complete the configuration needed for the agent-assisted payments feature and prepare to build the actual payments tab. The lesson starts by exporting the private key from the proposer wallet using a browser wallet extension. It includes an important security warning: private keys should never be shared for real operating wallets, because anyone with the key can fully control that wallet. In this exercise, the key is used only because the proposer wallet is empty and created for educational purposes.

The lesson then confirms that the .env.local file is now complete. It contains all required variables: the Safe address, proposer private key, Safe API key, and Moralis API key. With the Safe created, activated, and configured with an agent proposer, the setup is ready for the next step: building a simple UI where users can add vendor addresses and initiate payment proposals from the dashboard.

The walkthrough also explains how to prompt Claude to build the feature. Instead of writing a very technical specification, the user can describe the desired outcome in plain language: build a payments tab on the existing dashboard, use the screenshot as a reference, and rely on the variables already stored in .env.local.

Finally, the lesson connects the local setup with cloud deployment. It explains that environment variables must also be added to the deployed Vercel project, so the online version of the app can access the same configuration without exposing secrets in the code. The lesson shows how to add variables like the Safe API key, proposer private key, and Safe address to the cloud environment before pushing the updated app online.

Key topics covered:

• Exporting a wallet private key

• Private key security basics

• Why only empty test wallets should be used for this exercise

• Completing the .env.local configuration

• Safe address, proposer private key, Safe API key, and Moralis API key

• Preparing the agent-assisted payments feature

• Prompting Claude to build a payments tab

• Using screenshots as UI references

• Local environment variables vs cloud environment variables

• Adding secrets to Vercel deployment settings

• Preparing the app for online deployment

In this lesson, we continue building the agent-assisted payments feature and prepare the deployed app environment. The lesson starts by adding the remaining environment variables, including RPC URL and RPC timeout, then saving the configuration and redeploying the project so the cloud version has access to all required settings.

While Claude works through the Safe SDK and installs/checks dependencies, the lesson shifts into practical advice for building with AI agents. The main recommendation is to experiment a lot and build iteratively. Bugs are expected, but modern coding agents can often detect, test, and fix issues during the build process, especially when the work starts with a clear planning phase.

The lesson emphasizes that for larger features, it is better to start with a plan using a stronger model, then execute with a faster or cheaper model. It also warns against trying to build everything at once — instead of building a “Death Star,” the better approach is to build feature by feature. In this workshop, that means first creating the crypto dashboard, then adding the payments module on top of it.

The lesson also covers how useful existing files can be when building AI-assisted tools. Models can now understand Excel files, documents, and structured data well, so users can upload source files and explain what the tabs, rows, and columns mean. This can help turn spreadsheets into dashboards, forecasts, and other interactive tools much faster.

Key topics covered:

• Adding remaining environment variables

• Redeploying the cloud app

• Claude exploring the Safe SDK

• Dependency installation and safety checks

• Building with AI agents through iteration

• Starting complex work with a plan

• Using stronger models for planning

• Executing with faster models after planning

• Building feature by feature instead of all at once

• Restarting from scratch when the first build is wrong

• Turning Excel files into dashboards

• Using source files as context for AI-assisted builds

Lesson description

In this lesson, we test the newly built payments tab in the crypto dashboard. Claude launches the app with the preview tool, and the dashboard now includes a new payments section showing the Safe address, vendor management, and a simple interface for initiating payments.

The walkthrough shows how to open the Safe address, confirm that the Safe is currently empty, and check that there are no transactions in the queue. Then, a vendor is added using the signer wallet address, and the user attempts to propose a test payment through the new interface.

The lesson also demonstrates a realistic debugging flow. The first issue is that the Safe API key is not being passed correctly into the application, even though it exists in .env.local. The error is copied back into Claude, which identifies a one-line fix. After applying the fix, a second issue appears: the Safe API returns an “unprocessable content” error when proposing the transaction. This becomes an example of why planning and model choice matter: building quickly with a simpler model can work, but it may create more bugs that need to be fixed through iteration.

The broader takeaway is that AI-assisted development is not always a straight path. You build, test, hit errors, give the error back to the agent, and let it inspect the code or documentation more carefully. This lesson shows that debugging is a normal part of the workflow, especially when integrating external APIs like Safe.

Key topics covered:

• Testing the new payments tab

• Using Claude’s preview tool

• Viewing the Safe address from the dashboard

• Opening the Safe interface

• Checking transaction queue status

• Adding vendors to the payments UI

• Proposing a test payment

• Debugging missing environment variables

• Passing API keys correctly into the app

• Handling Safe API errors

• Understanding “unprocessable content” errors

• Iterating with Claude after bugs appear

• Why planning and model choice matter for complex integrations

Lesson description

In this lesson, we confirm that the agent-assisted payments flow works locally and then push the updated application online. The lesson starts by showing that vendor data is still not persisted properly, which reflects the current limitations of the local database/storage setup.

The main test is proposing a transaction through the payments tab. This time the transaction proposal works, and the Safe interface shows the created transaction details. The lesson also introduces the concept of a nonce: a unique transaction number used by the wallet/Safe. Because multiple transactions were proposed without being executed, they appear as conflicting transactions with the same next available nonce.

After confirming the local payments feature works, the lesson shows how to push the latest code changes to GitHub. Claude checks what changed since the previous commit, creates a new commit, and updates the repository. Then Vercel automatically detects the new GitHub commit and redeploys the online version of the app.

The lesson then tests the deployed version and finds that the payments tab is visible online, but the Safe information does not load correctly. This highlights an important architecture difference: local files and local databases do not automatically work the same way in a cloud deployment. To make the app fully work online, the database and secrets need to be properly structured for the deployed environment, likely using Vercel storage or another online database.

The broader takeaway is that deployment is also an iterative process. Once the app is live, you test what works, identify what breaks in production, and ask Claude to fix the architecture step by step. The foundation is now in place: admin page, dashboard, and payments tab — and more modules like cash flow, payroll, or other finance workflows can be added on top.

Key topics covered:

• Testing the payments tab locally

• Proposing a Safe transaction

• Viewing transaction details in Safe

• Understanding transaction nonces

• Conflicting queued transactions

• Pushing code changes to GitHub

• Creating a new commit

• Automatic Vercel redeployment

• Testing the deployed app

• Local storage vs cloud storage

• Why deployed apps need online databases

• Debugging missing Safe/environment data online

• Iterating after deployment

• Extending the dashboard with more finance modules

Lesson description

In this lesson, we finish testing the deployed version of the crypto dashboard with the payments feature. The lesson starts by confirming that the Vercel deployment is live and that the Safe is now correctly connected in the online application.

The walkthrough shows another round of testing: adding a wallet, checking that the dashboard works, adding a vendor address, and trying to initiate a payment from the deployed app. When an error appears, the lesson demonstrates the same practical debugging workflow: copy the error, share it with Claude, apply the fix, redeploy, and test again.

After the fix, the online app successfully proposes a transaction. The lesson confirms that the dashboard can now show asset information, initiate Safe transactions, and display the created transaction on-chain. This completes the main build: an online crypto dashboard with basic portfolio visibility and agent-assisted payments.

The final part introduces an important next-level idea: once the transaction logic exists in the codebase, it does not need to be used only through the UI. The same functionality can also be triggered through chat or later wrapped into an AI skill. This means that a user could ask Claude in plain language to send a payment using the existing code, and Claude can execute the same backend logic without manually clicking through the interface.

Key topics covered:

• Final testing of the deployed Vercel app

• Confirming Safe connection online

• Adding wallets and vendors in the deployed app

• Debugging production deployment issues

• Redeploying after fixes

• Initiating Safe transactions from the online dashboard

• Viewing proposed transactions on-chain

• Local deployment vs cloud deployment complexity

• Building features iteratively with Claude

• Reusing app logic outside the UI

• Triggering payments through chat

• Turning app functionality into AI skills