Intro to Algorand PyTeal Smart Signatures: 2026 Guide

Algorand supports two kinds of onchain programs that can approve transactions. A smart contract, also called an application, is stored onchain and can keep state in global and local storage. A smart signature, also called a logic signature or LogicSig, is a small program written in TEAL, the assembly-style language the network executes. It returns approve or reject for a transaction that is attached to it.

Smart signatures are stateless. They can read the transaction they belong to, the other transactions in its atomic group and some global values, but they cannot write to storage. That limit makes them small, cheap and predictable, which suits certain jobs well.

Good fits include:

• Escrow accounts that release funds only when stated conditions are met
• Time-limited payments that can only be sent before or after a given round
• Pre-authorized transfers that a delegate may submit within fixed limits
• Checks inside a larger atomic group, such as confirming a matching payment at a specific position

Poor fits include order books, lending pools, shared counters and anything that must track balances across many users over time. Those cases need a stateful application. Deciding which tool you need before writing code saves a lot of rework, so write down what state, if any, your logic must remember between calls.

If your program needs no memory and only answers yes or no about a transaction, a smart signature is a reasonable choice. If it needs to remember anything, plan for an application from the start.

Before writing code, it helps to see how the two options differ. The table below summarizes the main points. Confirm exact limits, such as program size and opcode budgets, in the current Algorand developer documentation, because these parameters can change between protocol versions.

Feature	Smart signature	Stateful application
Storage	None	Global and local state
Language	TEAL, often generated by PyTeal	TEAL, often generated by PyTeal
How it runs	Attached to a transaction and checked when that transaction is submitted	Called by an application call transaction
Typical use	Escrow, delegated approvals, group checks	Lending pools, registries, multi-user logic
Authorization	Contract account or a delegated signature	The application's own logic and the caller's signature
Upgrade path	Usually a new program and new address	Update logic if the app allows it

The upgrade row matters more than it looks. A smart signature's address is derived from its compiled bytes, so changing the program produces a new address. Any funds held by the old address must be moved deliberately. Applications can often be updated in place if the creator keeps that permission, which is one reason teams choose them for evolving products.

A common pattern is to combine both. An application holds the business logic and state, while a smart signature acts as a narrow escrow or check that only accepts transactions the application expects. This keeps each program focused and makes the security boundary easier to reason about.

You need a Python environment and the Algorand tooling. The steps below describe the general order. Because install commands and package versions change, follow the current official Algorand developer documentation for exact commands.

1. Install a recent version of Python 3 and create a virtual environment so project packages stay separate from your system.
2. Install the AlgoKit command-line tool, which manages local networks, project templates and common tasks.
3. Start a local development network through AlgoKit. This gives you a private chain for testing without real funds.
4. Install the PyTeal package and the Algorand Python SDK into your virtual environment using pip.
5. Create a project folder with a simple structure: one file for your program, one for compilation, and one for tests.

Keep the local network running while you develop, and check that you can create and fund a test account. If the local setup fails, the logs from the node and the tooling usually point to the cause, such as a port already in use or Docker not running.

For the tests in later steps, install a test runner you already know. Python's standard unittest module is enough for a first project. Store test accounts only on your local network, and never reuse a mnemonic from a test environment for real funds.

When the environment works, you should be able to run a short script that connects to the local node and prints the current round. That confirms the SDK and the node can talk to each other before you add contract logic.

PyTeal programs are Python functions that return an expression tree. When compiled in signature mode, the expression must evaluate to an integer, where a nonzero value approves the transaction and zero rejects it. The starter below approves only payment transactions with a capped fee and no rekey or close-to fields. It is a teaching example, not a complete escrow.

from pyteal import *

def payment_guard():
 return And(
 Txn.type_enum() == TxnType.Payment,
 Txn.fee() <= Int(1000),
 Txn.rekey_to() == Global.zero_address(),
 Txn.close_remainder_to() == Global.zero_address(),
 )

Each line does a specific job. The type check ensures the transaction is a payment. The fee cap limits how much the transaction can cost. The rekey and close-remainder checks prevent the transaction from handing control of the account or sending its full balance elsewhere. Those last two checks matter a great deal, and beginners often omit them.

PyTeal provides operators such as And, Or and Not, plus comparisons and access to transaction fields through the Txn object. Read the PyTeal documentation for the full list, because the names of helper functions and their arguments evolve with releases.

Start with something this small, compile it, and confirm it behaves as expected before adding conditions. Adding one rule at a time makes it much easier to find which rule caused an unexpected rejection.

Compiling turns the PyTeal expression into TEAL source and then into the bytecode the network runs. In your compile script, call the compile function from PyTeal with the program and the signature mode, and choose a language version supported by the current network. Write the TEAL output to a file so you can read it.

A typical script looks like this in outline: import compileTeal and Mode from PyTeal, call compileTeal on your program function with the mode set to signature, pass the version you chose, and save the returned string. The exact argument names should be checked against your installed PyTeal version.

Next, compile the TEAL into bytecode using the Algorand command-line tooling, such as the clerk compile command in goal. The output includes the compiled program bytes and the logic address. That address is derived from the program, so any change to the source, including a comment that changes the output, yields a different address.

Read the TEAL file line by line at least once. You are checking that each branch of your logic appears and that no unexpected operations were introduced. This habit catches mistakes that tests can miss, such as a comparison written against the wrong field.

Keep a record of the program version, the compiled bytes and the address for every build you plan to deploy. When you later fund or sign with an address, you will want to confirm it matches the build you reviewed.

Smart signatures often need inputs such as a recipient address or a deadline. Those values are passed as arguments attached to the transaction and read inside the program with an argument accessor. Keep arguments few and typed clearly, because each one is data the program must validate.

Group transactions let several transactions succeed or fail together. A smart signature can inspect other members of its group. Useful checks include confirming the group size, confirming the index of the current transaction, and reading a field from a specific transaction in the group. For example, your program might require that transaction zero in the group is a payment to a known address with an exact amount.

When you write group checks, be explicit about the position of each transaction. If you do not check the group size, a caller may add extra transactions that change the meaning of the group. Pair every positional read with a check that the group has the shape you expect.

Avoid trusting arguments without validation. Treat every argument as if an attacker chose it, because on a public network that is exactly what can happen. Compare addresses, amounts and round numbers against fixed values or other transactions in the group, and reject anything that does not match.

Document the expected group layout next to the code. Future maintainers and reviewers will need that description to understand which transactions the program assumes are present.

Testing happens in layers. Start with unit tests on the PyTeal functions, then run compiled programs through simulated transactions, and finally run end-to-end flows on a test network. Each layer catches different problems, so skipping one tends to leave gaps.

For unit tests, build a small set of transactions with known fields and check that your program approves the valid ones and rejects the invalid ones. Write a rejection test for every rule. A rule that is never tested in the negative direction may be wrong without anyone noticing.

Dry runs let you evaluate a program against a transaction before submitting it. The goal command offers a dry-run mode that reports whether the program passes and shows the trace. Use dry runs to step through edge cases, such as a fee exactly at the cap, a fee one unit over, and a missing argument.

Test these cases at minimum:

• A valid transaction that should pass
• A transaction with a fee above the limit
• A transaction that sets a rekey address or a close-to address
• A wrong transaction type
• A group with the wrong size or the wrong order
• Missing or malformed arguments

Run the full set after every change to the program, and keep the tests in version control next to the code. Automated tests make refactoring safer and give reviewers evidence of what the program is meant to do.

There are two common ways to authorize with a smart signature. In the first, a contract account, the logic address itself is the account. Funds sent to that address are controlled entirely by the program, and transactions from it are approved only when the program accepts them. This is the usual model for escrow.

In the second, a delegated signature, a normal account owner signs the compiled program with their private key. The signature lets the program act on that owner's behalf, within whatever limits the logic defines. The owner keeps the ability to revoke by moving funds or changing their own setup, so this model suits pre-authorized spending by a bot or a service.

Use the Algorand SDK to create a logic signature object from the compiled bytes, attach any arguments, and sign it when delegating. Keep signing keys offline where possible, and sign only programs you have reviewed, because a delegated signature can authorize any transaction the program allows.

Remember that once a compiled program is submitted to the network, it is public. Anyone can read the bytes. Do not embed secrets such as private keys, API tokens or passwords in the program or its arguments, because they will be visible to everyone.

Fund the contract account only after testing on a test network. Confirm the funded address matches the reviewed build, and record the transaction identifiers for your deployment log.

Before any mainnet use, review the program against a checklist. Most serious losses from account-level logic come from a short list of mistakes, so check each item explicitly rather than assuming it is covered.

• Rekey: confirm the program rejects any transaction that changes the authorizing address, unless that is intended.
• Close-to fields: check both the payment close-remainder field and the asset close-to field, so the full balance cannot leave in one transaction.
• Fee: cap the fee so a caller cannot drain value through excessive fees.
• Expiry: set a last valid round where a time limit matters, so an old approval cannot be used indefinitely.
• Lease: consider the lease field if you need to prevent the same transaction from being submitted more than once in a period.
• Group shape: confirm the group size and the position of every transaction the logic reads.
• Arguments: validate every argument against a fixed value or the group, and reject anything unexpected.
• Source review: have someone who did not write the program read the TEAL, not only the PyTeal.

Also confirm that your key management is sound. Keep signing keys offline where practical, use hardware-backed storage for keys that control meaningful funds, and separate test keys from production keys completely.

Finally, plan for failure. Decide in advance who can respond if something goes wrong, what the recovery steps are, and how users will be informed. A clear plan is part of a secure deployment.

The official Algorand developer documentation and tutorials are the best starting point for current tooling, command syntax and protocol details. The PyTeal documentation covers the Python library in depth, including its operators and cryptographic helpers. Read both alongside your own code so the examples match the versions you have installed.

After the starter, build a slightly larger project. A good next exercise is a time-locked escrow with a single recipient and a fixed amount, then extend it into a group check with a matching payment. Each step adds one new concept, so you can test as you go.

Study audited or widely reviewed examples to see how experienced developers structure their checks. Compare their approach with the checklist in this guide and note where they handle edge cases you had not considered.

If you plan to build a product that reads Algorand data, look at indexing and analytics tools to track transactions and program activity. The DefiLlama data site is useful for understanding how value flows across chains, and Envio offers indexing infrastructure for developers who need structured onchain data.

Keep your skills current by reading release notes for the language version and the SDK whenever you upgrade. Small changes in opcodes or helper functions can affect what your compiled program does, so test again after every upgrade.