ASI New User FAQ: Wallets, Crypto Payments, and Deployment Flow

Overview

Agent Service Index (ASI) works differently from most APIs in two primary ways: 1. Payments on ASI are in cryptocurrency. 2. Authentication and verification work through cryptographic signing.

Do I need to know crypto to use ASI?

Not deeply, but you should understand the basic flow.

Some ASI services are free. Some services may require small payments in USDC on Base, an Ethereum Layer 2 network. When a paid service is needed, the agent should show you the exact amount before anything is paid.

For most users, the practical flow is:

1. The agent creates or uses a local Ethereum wallet.
2. The agent determines what services are needed to accomplish the task and retrieves quotes from those services.
3. You approve funding or payment.
4. You use a hosted checkout/onramp page if funding is needed.
5. The agent completes the workflow after payment confirms.

ASI itself does not need your credit card details.

Why does ASI use cryptographic identity instead of API keys?

ASI is designed around agent-native services. Cryptographic identity gives the agent a consistent way to authenticate and own resources without needing to manage a separate API key for each service and resource. The secure process for authentication is:

1. Your agent leases a resource, identifying itself using its public key.
2. The service provider stores the public key to track what resources your agent leased.
3. Your agent contacts the service provider to use the resource it leased, identifying itself with a signature that it created with its private key.
4. The service provider uses the public key to verify that your agent is who it claims to be.

What should agents explain before using paid ASI services?

Agents should explain:

• What service will be used.
• Why it is needed.
• Whether it is free or paid.
• The maximum possible cost.
• Whether payment is one-time or recurring.
• What wallet/file will be created.
• What the user needs to keep secure.
• Whether a public resource will remain running.
• How to stop or delete the resource later.

For paid flows, the agent should get user approval and budget limits before starting.

Deployment Flow - Cloud and CDN Agent Services

What is the basic ASI deployment flow?

A common deployment flow looks like this:

1. The agent searches ASI for a relevant deployment, CDN, cloud, DNS, or tunnel service.
2. The agent reads the selected service's live documentation.
3. If authentication is required, the agent creates or reuses a local Ethereum wallet as its identity.
4. If payment is required, the service returns a quote.
5. The user approves or funds the quoted amount.
6. The agent retries the service call after payment.
7. The service creates the resource, such as a tunnel, subdomain, cloud instance, or route.
8. The agent returns the public URL or final result.

Does every individual site incur a registration charge?

Not necessarily.

Some services may charge a one-time wallet registration fee. For example, a CDN service might charge once to register a wallet, then allow that registered wallet to create tunnels or routes for free within service limits.

That means the charge is for the wallet's registration with that service, not necessarily for each individual site.

Always check the current service quote and pricing before paying. ASI services should return an explicit payment request before funds are spent.

Is a service registration global or just for one project directory?

A service registration is usually tied to the Ethereum wallet address, not a project directory.

All design pattern skills instruct agents to store their credentials at the following location, shared by any project on your machine:

~/.asi/config.json

Global ASI credentials stored at ~/.asi/config.json include:

• the wallet address
• service registration tokens tied to that wallet
• resources owned by that wallet

What are service limits?

A service may allow free usage after registration but still enforce limits. These are to prevent abuse.

Examples might include:

• Maximum number of active tunnels.
• Maximum number of DNS records.
• Maximum number of cloud instances.
• Rate limits on create/update calls.
• Time limits on leased resources.

The agent should read the service's live documentation and explain relevant limits before relying on the service.

What happens if I stop the local server or tunnel?

If a public URL depends on a local server and a tunnel process, both processes must keep running.

For example, a local static site served through a Cloudflare Tunnel needs:

• The local web server process.
• The tunnel process.
• The machine to stay online.

If either process stops, the public URL may stop serving until the agent or user restarts it.

How do I stop or clean up a deployed resource?

The agent should use the same Ethereum identity that created the resource.

Depending on the service, cleanup might involve:

• Deleting a tunnel.
• Deleting a DNS route.
• Terminating a cloud instance.
• Stopping a local process.
• Removing local helper files if no longer needed.

Resource ownership is usually tied to the Ethereum address, so losing the wallet may prevent cleanup.

Local Environment

The configuration of your local environment is entirely up to you; ASI requires no local configuration. Below are some best-practices.

Should I use uv to manage the environment?

Yes, for most local ASI helper workflows, a project-local uv environment is the right choice.

Packages like eth-account, web3, and httpx are usually needed for ASI signing, payment, and service-call workflows. Keeping them local avoids polluting your system Python and makes the setup reproducible.

Recommended:

uv venv
uv pip install eth-account web3 httpx

Then run helper scripts with:

uv run python ...

or directly with:

.venv/bin/python ...

A global install is only worth it if you expect to use these packages across many unrelated projects from the same Python environment.

Are local helper scripts part of ASI?

Not necessarily.

An agent may create local helper scripts to call ASI services, sign requests, check balances, or run deployment commands. These scripts are usually project-specific convenience code.

The Ethereum identity itself usually lives outside the repo in ~/.asi/config.json.

Wallets

What is ~/.asi/config.json used for?

~/.asi/config.json stores the local Ethereum identity used to authenticate to ASI-compatible services.

It is used for three main things:

1. Signing service requests Some services require EIP-191 wallet identity headers: X-Public-Key, X-Signature, and X-Timestamp. The agent signs requests locally using the private key in ~/.asi/config.json.
2. Owning resources If a service creates a resource for you, such as a tunnel, subdomain, cloud instance, or deployment, your Ethereum address can become the owner of that resource. The same address is then used to list, update, or delete it later.
3. Paying invoices when required If a paid service returns a 402 payment request, the wallet can be funded and used to pay the invoice. Creating the wallet file alone does not make a payment.

The file looks structurally like this:

{
  "wallets": {
    "default": {
      "address": "0x...",
      "private_key": "..."
    }
  }
}

Important details:

• The file is local to your machine.
• It should be locked down with chmod 600 ~/.asi/config.json.
• The private key should never be printed, pasted, committed, uploaded, or shared.
• The public address is safe to display.
• Without this file, the agent cannot make authenticated calls to many ASI services.

Why does the agent need a wallet?

The wallet is both:

• An identity, used to sign requests.
• A payment source, when paid services are needed.

This avoids API keys, manual account setup, and complicated agent-funding workflows. The wallet address can own resources across services, and the private key signs requests locally.

Do I need to keep my wallet address secure?

No. The wallet address is public by design, like an account number.

Keep these secure:

• ~/.asi/config.json
• the private_key inside it
• tunnel tokens
• payment tokens

Privacy caveat: blockchain transactions are public. Someone who knows your wallet address may be able to see visible on-chain activity for that wallet.

Should I keep funds in my ASI wallet?

Keep only a small working balance.

The ASI wallet should be treated as a low-value operational wallet for agents. It should not be your personal wallet, savings wallet, or primary crypto wallet.

Recommended practice:

• Use a dedicated ASI wallet.
• Fund only what you need.
• Keep balances small.
• Rotate wallets if a key may have been exposed.

What happens if I lose ~/.asi/config.json?

You lose access to that Ethereum wallet, the cryptocurrency contained in that wallet, and any services that were bought using that wallet.

That may mean you lose the ability to manage resources owned by that wallet, such as tunnels, DNS records, leases, or registrations.

For low-value test wallets, this may not matter much. For production use, back up the wallet file securely or use a more deliberate key-management process.

Is my wallet secure?

Your Ethereum wallet is secure if you follow best practices. ASI never sees or touches your private key.

Can ASI recover my wallet if I lose the private key?

No.

The Ethereum wllet is self-custodied. ASI services verify signatures from your key, but they do not hold the key and cannot recover it for you.

Should I commit ~/.asi/config.json to my repo?

No.

Never commit private keys. Add patterns like these to .gitignore if your project stores any local copies or generated secrets:

.asi/
*.key
*.pem
.env

The default ~/.asi/config.json location is outside the repo, which helps reduce accidental commits.

Crypto Payments

What is USDC?

USDC is a dollar-denominated stablecoin. In ASI payment flows, services commonly request USDC on Base.

Important points:

• USDC is not the same as a credit card charge.
• USDC transactions happen on-chain.
• The network matters. If the service asks for USDC on Base, use Base, not Ethereum mainnet or another chain.
• Sending funds to the wrong network or address can result in lost funds.

What is Base?

Base is an Ethereum Layer 2 network. It is commonly used because transactions are cheaper and faster than Ethereum mainnet.

When funding or paying an ASI invoice, make sure the checkout or wallet says the network is Base.

What does my agent actually control?

You agent controls an Ethereum cryptocurrency wallet. The wallet only includes the money you deposited into it; the agent can never spend beyond the exact amount you deposited into its wallet. Using cryptocurrency ensures that your agent can act independently without having any access to your finances.

What is a 402 payment request?

A 402 response means "Payment Required."

In ASI flows, a paid service may return a structured quote instead of completing the request immediately. The quote usually includes:

• Amount required.
• Currency, usually USDC.
• Network, usually Base.
• Destination address.
• Quote or invoice ID.
• Expiration time.

After the payment is made, the agent retries the original request with the quote ID.

Does ASI get access to my credit card?

No.

If funding is needed, your credit card is used through a third-party onramp or checkout page, typically Coinbase-hosted. ASI does not receive your card number.

The usual flow is:

1. The agent creates or shows a wallet address.
2. If payment is needed, you open a hosted checkout/onramp page.
3. You enter card details on that secure checkout page, not in ASI.
4. The checkout sends crypto to the specified wallet or invoice address.
5. The agent uses the resulting funds or payment confirmation to continue.

This is not a subscription unless a specific checkout provider separately says so. For ASI service invoices, the normal pattern is one-time payment for a quoted amount.

Can payment happen automatically?

Only if the wallet already has funds and the agent has permission to spend them.

A good agent should ask for spending permission up front, including a maximum budget. For example:

"Use ASI services if needed, but do not spend more than $3."

What should I check before approving a payment?

Check:

• The service name.
• The reason the service is needed.
• The exact amount.
• The currency.
• The network.
• Whether the payment is for a registration, resource, compute lease, route, or other action.
• Whether the quoted amount fits your spending cap.

If anything is unclear, ask the agent to explain before funding or paying.

What happens if I send payment to the wrong address or network?

Crypto transactions are generally irreversible.

If a service asks for USDC on Base, make sure the checkout or wallet uses:

• Asset: USDC
• Network: Base
• Address: exactly the quoted destination address

Sending to the wrong address or wrong network may result in lost funds.

Generally, agents will transact in small micropayments, making missteps cheap to correct.

Security

Is this secure?

It is secure if you treat ~/.asi/config.json like any other private key file.

What matters:

• The private key stays on your machine.
• ASI services receive only your public address, timestamp, and signature.
• The signature proves ownership for one request; it does not reveal the private key.
• File permissions matter. Use chmod 600 ~/.asi/config.json.
• Do not commit the file to git.
• Do not paste the private key into chat, logs, issues, or support requests.
• Use this as a low-value agent wallet. Do not reuse a personal wallet or store meaningful funds in it.

The main security model is: your local machine holds the key, and services verify signed requests.

Do I need to worry about any Agent Service's security?

ASI does not vet the services available through the search endpoint. Evaluate the security of Agent Services on a case-by-case basis.

ASI services should not be able to steal your private key if it never leaves your machine. However, services can control the resources they create for you. For example, a CDN service may create a tunnel or subdomain, and a cloud service may create a compute instance.

The practical risk is low if you:

• Use a fresh Ethereum wallet when storing on external services.
• Fund only the amount needed.
• Avoid storing large balances.
• Delete resources you no longer need.

What should I never share?

Never share:

• Private keys.
• ~/.asi/config.json.
• Tunnel tokens.
• Service secrets.
• Webhook secrets.
• Recovery phrases.
• Personal wallet credentials.
• One-time payment or auth tokens unless the service explicitly says they are safe to share.

What is safe to share?

Usually safe:

• Wallet address.
• Public deployment URL.
• ASI service name.
• Non-sensitive logs with secrets removed.
• Transaction hash, if you are comfortable with the associated wallet activity being public.

What if I think my Ethereum wallet private key was exposed?

Treat the wallet as compromised.

Recommended response:

1. Stop using that wallet.
2. Create a new Ethereum wallet and move remaining funds to the new wallet.
3. Re-register with services if needed.
4. Recreate or transfer resources where possible.
5. Delete exposed secrets from repos, logs, and chat history where possible.