Skip to content

[CAP-73] Small clarification regarding muxed account support. #1873

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dmkozh merged 3 commits into from
Feb 4, 2026
Merged

[CAP-73] Small clarification regarding muxed account support. #1873

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
58bb451
[CAP-73] Small clarification regarding muxed account support.
dmkozh Feb 2, 2026
05d0ad8
Update core/cap-0073.md
dmkozh Feb 2, 2026
0b41ca9
Merge branch 'master' into cap73_mux
dmkozh Feb 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions core/cap-0073.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,7 @@ Besides these differences, the trustline creation semantics are directly transla
#### XLM transfer creates `AccountEntry`

When an XLM transfer is performed to a G-address that does not exist yet (i.e. it does not have a respective `AccountEntry`), Soroban host will attempt to create a new `AccountEntry` for it. Specifically, it will create a new `AccountEntry` with the full transfer amount as balance if the transfer amount is at least the minimum account balance (1 XLM as of this CAP). Otherwise, it will panic.
If the transfer destination is M-address, its G-address part will be considered to perform the logic described above.

This change affects both SAC functions that perform transfers: `transfer` and `transfer_from`.

Expand All @@ -108,6 +109,16 @@ Transfers to accounts without a trustline could initiate trustline creation in a

Over the last year over 98% of the active trustlines had limit over 1e18 (effectively unlimited, 95+% of trustlines are also at int64 max), so unlimited trust is going to be sufficient most of the time. For the remaining small amount of cases, it is not likely that there is a good generalized approach to managing the exact trustline limit on the contract side, so it's not obvious that a more granular function would actually end up being useful.

### No trustline creation events

There is no protocol-defined event for the trustline creation and thus `trust` function will not emit any events.

### Muxed account support

Since `transfer` function has support for muxed destinations, we need to take that into account for the purpose of this CAP. We create an underlying G-account in order to keep the semantics consistent for all kind of transfers (muxed id part normally has no impact on the on-chain contract logic beyond the events). The transfer will then proceed to emit a regular transfer event with `to_muxed_id` populated according to the existing semantics.

In case of the new `trust` function, muxed addresses are not supported. Even though trustline creation may be necessary to be performed before the actual transfer, there is no reason to pass a muxed address into the creation function itself. There is no event to be emitted that would contain the muxed id, and that would be generally inconsistent with the SAC interface that only supports muxed destination specifically for transfers.

### Backwards Incompatibilities

This CAP does not introduce backward incompatibilities.
Expand Down
Loading