Stellar CAP-84: How Muxed Contract Addresses Change Stellar Payments

Stellar CAP-84 and the New Address Format for Smart Contract Transfers

What happens when a single smart contract has to hold money for thousands of customers? On Stellar, the answer has been awkward. Stellar CAP-84 is a protocol proposal built to close that gap with muxed contract addresses.

The idea is simple. A contract address gets a 64-bit ID attached, so one contract can keep many off-chain balances apart. The change sits inside the Bell, Protocol 30 upgrade, which faces validator votes in November 2026.

What Is Stellar CAP-84 and What Does It Add?

A CAP is a Core Advancement Proposal, the format Stellar developers use to suggest changes to the base protocol. This one is numbered 84 and titled Muxed Contract Addresses. 

According to the protocol repository, the proposal currently holds an Accepted status and was created on June 24, 2026, with Jake Urban of the Stellar Development Foundation listed as both its owner and author. 

To follow it, start with muxed accounts. A muxed account is one Stellar account with an ID attached. Every customer gets a unique deposit address, yet all funds land in the same account. The business tracks who owns what off-chain. Exchanges and ramps already use this model.

Smart accounts had no equivalent. A smart account is run by a smart protocol instead of a plain keypair, so it can set its own spending rules, such as passkeys or multisig. Without muxing, a smart account holding customer funds could not tell incoming payments apart. The workaround was one contract per customer.

Stellar CAP-84 removes that workaround. It gives protocol addresses the same ID feature accounts already have.

How Do Muxed Contract Addresses Work Under Stellar CAP-84?

The proposal adds a new address variant to the protocol. It pairs a protocol ID with a 64-bit number. 

The text form starts with the letter W. The foundation describes the W as an upside-down M, chosen so developers can tell the two types apart quickly.

The CAP text puts the W payload at 40 bytes: the 32-byte contract ID plus the 8-byte multiplexing ID. That makes it 8 bytes larger than a normal protocol address. The specification calls the resource impact negligible.

When a token goes to a W address, it lands in the underlying protocol as usual. The ID travels in the transfer event, inside a field named to_muxed_id. The receiving application reads it and credits the right customer. Balances and authorization stay untouched.

What Changes for Exchanges, Wallets, and Developers?

The official upgrade guide treats Stellar CAP-84 as an action item for anything that handles addresses. Existing agreement keep working, and nothing breaks at the transaction level. The work sits in application code.

Key points from the guide:

• SDKs: Protocol 30 SDKs include a W address parser. JavaScript SDK v17.3.0 supports it, while the older v16.4.0 line decodes new ledgers but ignores W addresses.

• Type checks: Apps that validate, display, or store addresses will need to add the W variant to their type checks so that these addresses are recognized across every part of the application.

• Exchanges and custodians: Withdrawals to W addresses will need to be supported, and teams that currently rely on M addresses for deposits may consider whether the W format suits their setup better.

• Contract teams: A function declared with a plain address rejects a W address. One declared with MuxedAddress accepts both.

• Indexers and explorers: XDR definitions need updating before the upgrade, or decoders may fail.

Developers tracking the SDK upgrade deadline will find the same warning repeated. The effect is mostly operational. A crypto wallet that ignores W addresses could reject valid destinations, which is a support headache rather than a security flaw.

What Limits and Safety Rules Come With Stellar CAP-84?

The design is narrow on purpose.

• Destination only: A muxed contract address can receive a transfer. The sending side is not multiplexed.

• Transfer only: Support covers the Stellar Asset Contract transfer function. Mint and transfer_from were considered and postponed.

• Not for storage: The host rejects muxed contract addresses inside an agreement storage keys, since the ID is meant for off-chain routing.

• No authorization change: The muxed address behaves like its base contract for balances and permissions.

The available data suggests the authors wanted low risk. The proposal copies the account design from an earlier proposal, CAP-67, so SDKs and indexers can reuse logic built for M addresses. The tradeoff is scope. Teams needing multiplexed minting or source-side tracking would need a later proposal.

When Could Stellar CAP-84 Go Live?

The foundation says dates are subject to change. Each upgrade takes effect only if validators approve it.

What Remains Unconfirmed About Stellar CAP-84?

Several items are still open. The CAP lists its protocol version, test cases, and implementation section as TBD. The Bell announcement, however, places the change in Protocol 30. The final strike definition for W addresses also lives in SEP-23, a separate standard.

Adoption is the bigger unknown. No major crypto exchange or custodian has publicly confirmed W support in the official pages reviewed. Whether businesses move to smart accounts at scale depends on products, not on the protocol alone.

The announcement also says nothing about the XLM price. Any market effect would be speculation.

Conclusion

Stellar CAP-84 gives smart agreement a trick much more than accounts have offered for years: one address on-chain, many customers off-chain. It looks small, yet it removes a real obstacle for businesses holding customer funds in smart accounts.

What stands out is the careful scope. It copies a proven design, covers only transfers, and leaves authorization alone. What remains uncertain is the vote result and how quickly wallets and exchanges add W support.

Further details on the change are available in the CAP text on GitHub, while the official upgrade documentation and SDK release notes show how the update affects developers and node operators. 

Disclaimer:

This article is for information only and is not financial, legal, or investment advice. Crypto assets are volatile, and protocol upgrades can change or fail. Readers should verify details through official sources and do their own research.