# AVM fundamentals

Use this guide when design depends on what an Algorand program can observe,
change, or afford.

## Execution model

Algorand has two AVM program shapes:

- An **application** has an application ID and account, can keep state, receive
  app calls, inspect available ledger resources, log values, and issue inner
  transactions.
- A **Logic Signature** approves a transaction or delegates signing under a
  constrained stateless program. It does not provide application storage.

Applications run as part of an atomic transaction group. If any transaction or
program fails, the group fails. On-chain code has no network, filesystem,
threads, promises, clock APIs, floating point, or arbitrary package imports.
It sees only AVM values, transaction fields, declared/available resources, and
ledger data exposed by AVM operations.

Start with the [smart-contract overview](https://dev.algorand.co/concepts/smart-contracts/overview/)
and [AVM overview](https://dev.algorand.co/concepts/smart-contracts/avm/).

## Design against budgets

Before implementing a design, account for:

- opcode cost and pooled group budget;
- compiled program size and extra program pages;
- stack and byte-value limits;
- application arguments, logs, inner transactions, and group size;
- global/local state schema and account opt-in requirements;
- box references, box I/O budget, box size, and box minimum balance;
- foreign accounts, assets, applications, and other app-call resources;
- transaction and inner-transaction fees.

Do not freeze numeric limits into general guidance. Read the current
[costs and constraints](https://dev.algorand.co/concepts/smart-contracts/costs-constraints/)
and [resource usage](https://dev.algorand.co/concepts/smart-contracts/resource-usage/)
pages when a design is near a boundary.

## Protocol 5.0 implications

Protocol 5.0 introduced AVM v13, larger size-priced transactions and
applications, `poseidon2`, application-parameter mutation, new box parameter
and foreign-box operations, and variable-length branches. It also removed the
old `dryrun` endpoint and `tealdbg` tool in favor of simulation.

Use those capabilities only when the project's compiler and target network
support them. Larger limits do not remove fee, resource, or minimum-balance
costs. Diagnose transaction-size surcharges and inner-fee shortfalls with
`simulate`.

AVM v13 also salts programs automatically to avoid on-curve Logic Signature
hashes. After changing the target AVM version, regenerate and re-review a
Logic Signature's compiled address or bytecode instead of assuming it is
stable.

See the [5.0.0 release](https://github.com/algorand/go-algorand/releases/tag/v5.0.0-stable)
and focused [opcode-budget example](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/op_budget/contract.algo.ts)
rather than reproducing release notes or API catalogs.

# Clients and testing

Contract artifacts are the boundary between on-chain and off-chain TypeScript.
Prefer an ARC-56 artifact and a generated client over hand-encoding ABI calls.

## Generated clients

Use the project's existing client-generation script. Regenerate after changing
public methods, structs, events, state, template variables, or lifecycle
configuration. Do not hand-edit generated files.

Before calling a generated API:

1. Read the generated constructor and method types; generator versions differ.
   A client targets a known app ID, while a factory creates or deploys
   application instances.
2. Use the app ID and network selected by the project.
3. Pass the sender and signer explicitly unless the existing client factory
   deliberately registers defaults.
4. Build transaction arguments with the same `AlgorandClient`/algosdk context
   as the app call.
5. Use `bigint` for app IDs, asset IDs, and atomic amounts unless the generated
   type requires otherwise. Do display-unit conversion only at an input/output
   boundary.

The regenerated client is the authoritative API for this app. Lifecycle actions
are calls through it too — opt-in, close-out, update, and delete — and their
exact shape (e.g. `client.send.optIn`, often a nested `.bare()`) is
generator-specific. Read the entrypoint in the generated file to confirm it;
do not guess the call nesting or web-search the client API. A local-state write
needs the caller opted in first, so the opt-in is part of the change, not a
test detail.

Use the [TypeScript client-generator guide](https://dev.algorand.co/algokit/client-generator/typescript/).
For off-chain usage, prefer the runnable [application](https://github.com/algorandfoundation/algokit-utils-ts/blob/docs-staging/examples/concepts/applications.algo.ts)
and [transaction](https://github.com/algorandfoundation/algokit-utils-ts/blob/docs-staging/examples/concepts/transactions.algo.ts)
examples instead of reproducing the client API.

## Test at two levels

- **Unit tests** are fast and useful for contract branches, state transitions,
  AVM values, opcodes, and failure cases. Use the project's current Algorand
  TypeScript testing package and conventions. In PuyaTs projects, transformed
  AVM tests conventionally use `.algo.spec.ts` or `.algo.test.ts`; an ordinary
  test file does not automatically receive those semantics.
- **Compiled integration tests** exercise generated TEAL, real transaction
  groups, fees, resources, minimum balance, generated clients, and ledger
  behavior. They catch failures a TypeScript-level test cannot.

A passing transformed unit test does not prove compiled TEAL behavior, fees,
resource availability, or ledger effects. Keep both levels when the contract
controls value or authorization.

For every privileged or value-moving method, cover success and rejection:
wrong sender, wrong transaction field, boundary amount, repeated call,
missing resource, insufficient fee/balance, and unauthorized lifecycle action.
Test box creation and deletion with their minimum-balance effects.

Start from the [TypeScript unit-testing guide](https://dev.algorand.co/algokit/unit-testing/typescript/overview/)
and the project's existing end-to-end tests.

## Debug with simulation

On a logic failure, preserve the complete error, transaction group, app ID,
program counter, and source map. Simulate the same group with traces and
resource/fee reporting, then map the failure through the ARC-56 source info.
Do not retry a write blindly or fall back to removed `dryrun`/`tealdbg`
workflows.

# Frontend wallets

Keep wallet integration small. The wallet owns account selection and signing;
the generated client owns contract encoding; the frontend owns network and
app-ID configuration.

If the optional TxnLab catalog is installed, load its `use-wallet` skill for a
deeper integration. Otherwise, use the canonical
[use-wallet skill source](https://github.com/TxnLab/skills/tree/main/skills/use-wallet).
Use [use-wallet-ui](https://github.com/TxnLab/use-wallet-ui) when the product
wants a maintained connect/account UI rather than custom controls.

## Minimal React shape

For a browser-only SPA, create one `WalletManager` at module scope, configure
only supported wallets, and wrap the app with `WalletProvider`:

```tsx
import type { ReactNode } from 'react'
import {
  NetworkId,
  WalletId,
  WalletManager,
  WalletProvider,
} from '@txnlab/use-wallet-react'

const manager = new WalletManager({
  wallets: [{ id: WalletId.PERA }, { id: WalletId.LUTE }],
  defaultNetwork: NetworkId.TESTNET,
})

export function WalletRoot({ children }: { children: ReactNode }) {
  return <WalletProvider manager={manager}>{children}</WalletProvider>
}
```

In SSR frameworks, create a stable client-only manager; do not share a mutable
manager across server requests. Keep wallet network and algod configuration
aligned with the `AlgorandClient` used by the generated client. For use-wallet
v4, use its separate `useNetwork` API for network state and switching; do not
copy v3 provider snippets.

At the call site, hand the wallet signer directly to the generated method:

```tsx
const { activeAddress, transactionSigner } = useWallet()

if (!activeAddress) throw new Error('Connect a wallet first')

const client = new ExampleClient({ algorand, appId })
const result = await client.send.exampleMethod({
  args: { value },
  sender: activeAddress,
  signer: transactionSigner,
})
```

Inspect the generated client before copying this shape; constructor and method
names follow the project's generator version. Passing `sender` and `signer`
per call keeps authority visible. If the existing application registers a
signer on `AlgorandClient` instead, use that pattern consistently rather than
mixing implicit and explicit resolution.

See the public VibeKit starter's
[wallet setup](https://github.com/initlabsai/algorand-starter-fullstack/blob/main/app/src/App.tsx)
and [generated-client call](https://github.com/initlabsai/algorand-starter-fullstack/blob/main/app/src/components/AppCalls.tsx)
for a complete handoff.

## Browser constraints

- Require a connected address before constructing a write request.
- Initiate signing from a direct user action; popup and mobile wallets can
  reject signing started by an effect, timer, or background callback.
- Display the network, app, action, and material amounts before requesting a
  signature. Do not silently switch networks.
- Keep the wallet manager stable across renders and restore sessions only
  through the library's supported lifecycle.
- Gate wallet-dependent rendering until the adapter is ready in SSR apps to
  avoid hydration mismatches.
- Never put mnemonics, private keys, or secret signing material in browser
  state, environment variables shipped to the client, logs, or analytics.
- Treat rejection as a normal user outcome and do not auto-retry signing.

# Migrations

Migrate only after identifying the exact source and target versions. Do not
apply an old rename table wholesale.

## Establish the baseline

1. Read `package.json`, the lockfile, compiler config, generated artifacts,
   deployment metadata, and tests.
2. Compile and run the current test suite before changing APIs.
3. Record public ABI signatures, ARC-56/ARC-32 artifacts, state keys and
   encodings, schema, boxes, template variables, update/delete policy, and
   deployed app IDs.
4. Read the release-specific [PuyaTs migration guide](https://github.com/algorandfoundation/puya-ts/blob/main/docs/src/content/docs/migration-guides.md)
   and relevant client-library migration notes.

Preserve wire compatibility deliberately. A source-level refactor can still
change method selectors, tuple encoding, state layout, event signatures,
compiled program behavior, or deployment decisions.

## TEALScript or Algorand TypeScript beta

Move to current `@algorandfoundation/algorand-typescript` imports and compiler
syntax. Replace legacy decorators, storage wrappers, transaction builders,
copy semantics, and template-variable APIs only where the installed migration
guide requires it. Use current PuyaTs examples to reconstruct each pattern,
then compile after every small group of changes.

Do not preserve a legacy pattern merely because it type-checks. Confirm the
generated TEAL and application specification, especially around ARC-4 types,
array/object aliasing, boxes, inner transactions, and lifecycle methods.

## ARC-32 to ARC-56

Prefer ARC-56 for new generated clients. ARC-32 remains Final but its own spec
says it will eventually be deprecated by ARC-56. Regenerate from compiler
output when possible; do not manually translate a large JSON artifact.

Before replacing ARC-32, verify every consumer supports ARC-56 and compare:
methods, bare actions, structs, state, events, source maps, bytecode/template
variables, networks, and deployment metadata. Keep ARC-32 only as a deliberate
compatibility artifact when a current consumer still needs it.

## Operations belong elsewhere

This guide ends at compatible code and artifacts. In a VibeKit project, use
`use-vibekit` for LocalNet reset, accounts, deployment, and on-chain migration
operations. Never overwrite or replace a deployed application based only on a
successful local compile.

# PuyaTs contracts

PuyaTs compiles Algorand TypeScript into TEAL. Write for the AVM type system,
even though the syntax and editor tooling look familiar.

## Types first

- Never annotate a contract value as `number`. Use `uint64` for AVM integers,
  `biguint` when wider arithmetic is required, and `bytes` for byte strings.
- Use ARC-4 types when their ABI encoding is part of a public method or stored
  representation. Do not assume a native AVM value and its ARC-4 wrapper have
  identical operations or encoding.
- Give arrays and objects explicit types. Static arrays are cheaper and more
  predictable when the length is known.
- Arrays and objects are reference types. Assignment aliases the same value;
  use `clone(value)` when subsequent mutation must be independent.
- Do not use union-heavy domain models, exceptions, promises, dynamic property
  access, standard collection APIs, or JavaScript runtime globals unless the
  current language guide explicitly supports them.

Read the current [Algorand TypeScript guide](https://dev.algorand.co/concepts/smart-contracts/languages/typescript/)
and PuyaTs [type guide](https://github.com/algorandfoundation/puya-ts/blob/main/docs/src/content/docs/language-guide/types.md)
when a construct is uncertain. Let the compiler reject unsupported language
features; do not work around it with casts.

## Contract surface

Prefer an ARC-4 contract for an application intended for clients:

- expose ABI methods deliberately and keep helpers `private`;
- state allowed on-completion actions and creation behavior explicitly;
- use ABI transaction arguments for payments or transfers that a method must
  validate atomically;
- use readonly methods only when execution is actually side-effect-free;
- emit structured events only when consumers need them and follow ARC-28;
- make update and delete authorization visible in the contract.

Generated ARC-56 output is part of the public interface. Method names,
argument types, structs, state declarations, events, and lifecycle choices
affect generated clients; review the artifact after compilation.

## Use examples as the API reference

Prefer small, current compiler examples over copied syntax catalogs:

- [ARC-4 hello world](https://github.com/algorandfoundation/puya-ts/blob/main/examples/hello-world-abi/contract.algo.ts)
- [ARC-4 method options](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/abimethod_options/contract.algo.ts)
- [ARC-4 types](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/arc4_types/contract.algo.ts)
- [Typed cross-contract ARC-4 calls](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/arc4_client/contract.algo.ts)
- [Contract options](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/contract_options/contract.algo.ts)
- [Events](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/events/contract.algo.ts)
- [Auction: state, transaction arguments, and inner transactions](https://github.com/algorandfoundation/puya-ts/blob/main/examples/auction/contract.algo.ts)
- [Voting application](https://github.com/algorandfoundation/puya-ts/blob/main/examples/voting/contract.algo.ts)
- [All focused devportal examples](https://github.com/algorandfoundation/puya-ts/tree/main/examples/devportal)
- [All PuyaTs examples](https://github.com/algorandfoundation/puya-ts/tree/main/examples)

Follow the project's imports and compiler version. Do not transplant code from
a different release without compiling it locally.

# Security

Review contracts as authorization and asset-custody systems. Expected
happy-path results are only one part of correctness.

## Threat model

Identify:

- assets and state the application controls;
- privileged accounts and how authority can change;
- all public ABI and bare-call entry points;
- accepted group and inner transactions;
- application update/delete policy;
- state-growth, fee, resource, and minimum-balance payers;
- off-chain assumptions such as indexers, frontends, facilitators, and oracles.

Any field supplied by a caller or neighboring transaction is adversarial until
the contract checks it.

## Review checklist

- Authorize by an explicit address or durable role; do not confuse transaction
  sender, asset sender, application account, and creator.
- Validate transaction type, sender, receiver, amount, asset/app ID, and all
  close/rekey fields relevant to accepted transaction arguments.
- Protect against replay or duplicate execution where the operation is meant
  to be one-shot. Use state, leases, rounds, or unique identifiers as the
  design requires.
- Check arithmetic bounds and use the intended AVM/ARC-4 width. Avoid unit and
  decimal conversions inside authorization or accounting logic.
- Make checks before state changes and inner transactions. Preserve atomicity;
  do not create partially committed multi-step protocols across calls without
  an explicit state machine.
- Bound user-controlled loops, bytes, arrays, logs, and box growth.
- Fund minimum-balance increases intentionally and reclaim storage only under
  authorized, well-tested rules.
- Set inner-transaction fees to zero unless the application account is
  deliberately paying a bounded fee. Otherwise, a caller can drain its
  balance by making it absorb fees.
- Restrict update and delete. If immutability is intended, make it a deployment
  and contract invariant rather than a UI promise.
- Keep clear-state logic safe under its special failure semantics: local state
  is cleared even when the clear-state program rejects. Never rely on that path
  for custody, debt settlement, or a required exit action.
- Do not log secrets or sensitive plaintext. Logs and state are public.

Simulation provides diagnostic evidence. A successful simulation against one
ledger snapshot does not replace contract checks or grant authorization.

## Evidence before release

Compile with warnings treated seriously, review generated TEAL/source maps,
run negative tests for every privileged and value-moving path, and exercise
compiled integration tests with realistic groups and balances. Use the
[Puya security policy](https://github.com/algorandfoundation/puya-ts/blob/main/SECURITY.md)
and current [smart-contract constraints](https://dev.algorand.co/concepts/smart-contracts/costs-constraints/)
as starting points. A high-value or externally administered contract needs an
independent security review beyond ordinary agent-generated tests.

# Algorand standards

Use an ARC because a current consumer needs interoperability, not because it
appears in a broad checklist. Read the live specification and adoption data
before implementing it.

## Normal application path

- [ARC-4](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md)
  defines ABI method signatures, selectors, argument/return encoding, and
  interfaces. Use it for public application methods.
- [ARC-56](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0056.md)
  extends the application description with state, structs, events, source
  information, actions, and other data used by generated clients. Prefer it
  for new application artifacts.
- [ARC-28](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0028.md)
  defines structured application events. Use it when an indexer, client, or
  integration consumes typed logs.

## ASA and digital-asset choices

- [ARC-3](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0003.md)
  defines off-chain JSON metadata conventions for fungible and non-fungible
  ASAs. It remains the basic compatibility choice for ASA metadata.
- [ARC-19](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0019.md)
  defines mutable NFT URL templating, and
  [ARC-69](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0069.md)
  defines digital-media metadata in asset-config notes. Both are Final but are
  marked as superseded by ARC-89; support them when integrating existing
  assets and consumers.
- [ARC-89](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0089.md)
  proposes an ASA metadata registry and supersedes ARC-19/69. It is currently
  Last Call. For a new design, verify its latest status, trusted deployments,
  implementation maturity, and wallet/marketplace support before choosing it.
- [ARC-20](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0020.md)
  defines a Smart ASA controlled through an ARC-4 application. Use it only
  when the product needs contract-enforced asset behavior and its consumers
  support the interface.

Do not combine ARC-3, ARC-19, ARC-69, ARC-89, and ARC-20 by default. Choose the
smallest model that satisfies mutability, custody, metadata, and ecosystem
requirements.

## Specialized standards

Read these only when the corresponding feature exists:

- [ARC-2 transaction notes](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0002.md)
- [ARC-18 royalties](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0018.md)
- [ARC-55 on-chain multisig coordination](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0055.md)
- [ARC-72 application-based NFTs](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0072.md),
  currently Living
- [ARC-200 application-based tokens](https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0200.md),
  currently Living

Legacy and withdrawn standards are omitted from this selection. Consult the
repository history only when maintaining an integration that already depends
on one.

Browse the [ARC repository](https://github.com/algorandfoundation/ARCs/tree/main/ARCs)
or [developer-portal index](https://dev.algorand.co/arc-standards/) for current
status and category information.

# State and transactions

Choose storage and composition together: both affect minimum balance,
resources, fees, and the client call shape.

## Choose state deliberately

- **Global state** is small application-wide state that callers should be able
  to inspect directly.
- **Local state** belongs to an account/application pair and requires that
  account to opt in. Use it only when account opt-in is part of the product.
- **Boxes** support larger and dynamically keyed application state without
  account opt-in. The application account must fund their minimum balance, and
  calls must make sufficient box resources and I/O budget available.
- **Logs** are outputs, not durable application storage. Use ARC-28 when logs
  are intended as typed events.

State is declared with factory functions, not classes — `new` is a compile
error — and the option names are `key` / `keyPrefix`:

```ts
import { Box, BoxMap, GlobalState, LocalState } from '@algorandfoundation/algorand-typescript'

counter = GlobalState<uint64>({ key: 'c' })
score = LocalState<uint64>({ key: 's' })
config = Box<bytes>({ key: 'cfg' }) // one box, fixed key
greetings = BoxMap<string, string>({ keyPrefix: 'g' }) // one box per key
```

`this.greetings(name).value` reads or writes the box for `name`; `.exists`
checks first. The installed `@algorandfoundation/algorand-typescript/*.d.ts`
files are the authoritative API: when the compiler names a type it does not
recognize, read that type's declaration before guessing again.

Keep keys and encodings stable once clients depend on them. Bound user-created
state, decide who funds growth, and define deletion/refund behavior. A storage
proxy is not an ordinary JavaScript object: use only its supported write-through
operations. When loading a composite value into a local variable, clone it,
mutate the clone, and assign it back unless current compiler documentation
explicitly supports the in-place proxy operation.

Fund the application account before a box-creating call increases minimum
balance. Authorize deletion and define where any released balance may go; a
box refund is part of the value-flow design, not automatic user ownership.
Read the
[storage overview](https://dev.algorand.co/concepts/smart-contracts/storage/overview/)
and [box guide](https://dev.algorand.co/concepts/smart-contracts/storage/box/)
for current costs and reference rules.

## Validate group transactions

When an ABI method accepts a payment, asset transfer, or application-call
transaction, validate every field the invariant depends on. Typical checks
include:

- expected transaction type and group relationship;
- sender and intended receiver;
- exact or bounded amount in base units;
- asset ID or application ID;
- no unexpected `rekeyTo`, `closeRemainderTo`, or `assetCloseTo`;
- no unintended clawback, freeze, or asset-sender behavior;
- valid rounds, lease, note, and fee when they matter to replay or policy.

Never accept “some payment exists in this group” as proof that the application
received the required value.

## Inner transactions and resources

An application account is the sender of its inner transactions. Ensure it is
funded and opted into assets it must hold. Budget inner-transaction fees in the
outer group; fee pooling is useful, but a zero inner fee does not make the
group free.

Applications can read only resources available to the app call. Client-side
resource population and simulation reduce boilerplate, but contract
correctness must not depend on an undocumented client default. Declare or
populate accounts, assets, apps, and boxes intentionally.

Use the current PuyaTs [inner-transaction guide](https://github.com/algorandfoundation/puya-ts/blob/main/docs/src/content/docs/language-guide/itxns.md)
and focused examples for [global state](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/global_state/contract.algo.ts),
[local state](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/local_state/contract.algo.ts),
[box storage](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/box_storage/contract.algo.ts),
[group transactions](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/group_transactions/contract.algo.ts),
and [inner transactions](https://github.com/algorandfoundation/puya-ts/blob/main/examples/devportal/inner_transactions/contract.algo.ts).
For off-chain composition, use the AlgoKit Utils
[transaction examples](https://github.com/algorandfoundation/algokit-utils-ts/blob/docs-staging/examples/concepts/transactions.algo.ts).

# x402 on Algorand

x402 uses HTTP `402 Payment Required` responses to describe a payment. A client
constructs and signs the requested Algorand payment, a facilitator verifies
and settles it, and the resource server returns the protected response after
successful settlement.

Treat this as orientation only. The protocol, AVM packages, network
identifiers, supported assets, facilitator behavior, and middleware APIs are
moving quickly. Inspect the current TypeScript packages and examples before
writing code; do not copy package names or payload shapes from an old skill.

## Choose the operating model

- Start with the ecosystem's hosted
  [GoPlausible facilitator](https://facilitator.goplausible.xyz/guide) when its
  networks, assets, limits, trust model, and availability fit the product.
- Use the [Algorand x402 guide](https://dev.algorand.co/resources/x402-on-algorand/)
  for the current client/resource-server flow and package set.
- Consult the [AVM library documentation](https://github.com/GoPlausible/.github/blob/main/profile/algorand-x402-documentation/README.md)
  for implementation details, but verify every API against the installed
  version.
- Use the [WAD-26 demo](https://github.com/algorandfoundation/WAD-26-x402-demo)
  as the simplified reference when evaluating a custom facilitator.

A custom facilitator becomes security-sensitive payment infrastructure. It
must validate the complete transaction group, signatures, network, asset,
amount, recipient, fees, close/rekey fields, replay/expiry behavior, and any
facilitator-owned fee-payer transaction before settlement. Keep signing keys
outside application code and logs.

Use TestNet first and show the user the asset, atomic amount, payee, network,
and facilitator before requesting a signature. Do not assume a public
facilitator supports MainNet or a particular ASA merely because an example
does.