ARC-1 Wallet Transaction Signing API

ARC-1 is the Algorand Request for Comments that defines a standard API for transaction signing between a dApp and a wallet. It establishes a communication channel where a dApp can request that a wallet sign one or more Algorand transactions without exposing the user's private keys to the application. This standard is the bedrock of the Algorand dApp ecosystem, enabling every core user interaction—from token swaps and NFT purchases to governance votes and DeFi deposits—to occur in a secure, interoperable manner. It is the direct predecessor and conceptual foundation for the WalletConnect-compatible algorand provider interface, making it essential for any team building wallet or dApp infrastructure.

Operationally, ARC-1 defines a JSON-based request and response schema over a secure transport. A dApp sends a SignTxnRequest containing one or more serialized, canonical Algorand transactions. The wallet must decode and present these transactions to the user in a human-readable format for approval, a process critical to preventing blind-signing attacks. The wallet then signs the transactions with the user's private key and returns the signed stxn blobs in a SignTxnResponse. The standard's security model places a heavy burden on wallets to correctly parse every transaction field—including rekey-to, close-remainder-to, and asset clawback addresses—and display their implications clearly. Any parsing failure or UI omission by a wallet implementation creates a vulnerability where a malicious dApp can trick a user into signing a destructive transaction.

For builders and operators, ARC-1 is not just a legacy spec but a live integration surface. Wallet developers must audit their signing flow against this standard to ensure they are not introducing blind-signing risks, particularly when handling complex atomic transaction groups. dApp teams must ensure they construct transactions correctly and handle user rejections gracefully. Chainscore Labs provides protocol impact assessments and integration reviews for teams implementing or upgrading their ARC-1 flows, helping to verify that transaction parsing is secure and that the user consent mechanism is robust against the most common attack patterns in the Algorand ecosystem.

ARC-1 establishes a standard interface for Algorand wallets to receive, parse, and present transaction payloads from decentralized applications before a user authorizes signing. The flow begins when a dApp constructs one or more algosdk.Transaction objects and passes them to the wallet via a provider bridge, typically through a browser extension, mobile deep link, or WalletConnect session. The wallet is responsible for decoding every field—receiver, amount, asset ID, note, and application call arguments—and displaying them in a human-readable format. This decoding step is the critical security control: if the wallet fails to parse or display a field correctly, the user may approve a transaction whose effects they do not understand.

The security model relies on the wallet as the sole trusted display surface. The dApp is an untrusted actor that can construct arbitrary transaction payloads, including rekeying transactions, asset clawbacks, or smart contract calls that delegate authority. ARC-1-compatible wallets must therefore implement rigorous transaction inspection logic that goes beyond simple field display. This includes detecting rekey-to addresses, flagging close-remainder-to fields, decoding application arguments against a known ABI when available, and warning users when a transaction group contains an unexpected combination of operations. Wallets that treat ARC-1 as a simple pass-through signing interface introduce systemic blind-signing risk across the entire Algorand ecosystem.

For dApp developers, the operational responsibility is to construct minimal, auditable transaction groups and to avoid patterns that make wallet-side inspection difficult, such as encoding complex logic in opaque application arguments without providing an ARC-32 application spec. For wallet teams, the implementation burden is high: the signing flow must handle atomic transaction groups, simulate application calls to preview state changes, and maintain a continuously updated registry of known contract addresses and their ABIs. Chainscore Labs reviews both sides of this interface—auditing dApp transaction construction for unnecessary authority grants and evaluating wallet parsing logic for display-completeness gaps that could allow a malicious dApp to obscure the true intent of a transaction.