feat: Transaction Request URLs

[ganymedio]

No description provided.

[Primata]

I'd include the intent label as well in the description (e.g. pay), asset is a more important field. Believe we will need a table for asset= because we also want to enforce transfers of known assets only.

[ganymedio]

Done, the overview now names the intent and adds an asset example. On known-assets-only: kept the format open, but added that wallets MAY enforce a curated asset policy on top of on-chain verification. Enforcement fits wallet policy better than the wire format, since a list in the spec can't stay current.

[Primata]

alias registry might be mandatory.

[ganymedio]

Agreed it's likely where this goes, but it needs an on-chain registry + governance this MIP otherwise doesn't depend on. Added to Future Potential as a follow-on.

[Primata]

Suggested change

	- **Devnet / testnet:** used throughout Phases 2–4 for asset-resolution, expiry, and abort-path matrices.
	- **Testnet:** used throughout Phases 2–4 for asset-resolution, expiry, and abort-path matrices.

[ganymedio]

Right, no devnet, thanks... applied, both mentions.

[Primata]

For both the vendor and the user safety, there are a lot of steps that might fail. This brings back the offline signing by Sui, isn't it fairly dangerous to accept it? See line 241 At least one of the parties need to have connectivity, if vendor it would accept a signed message which it can propagate and verify, if signer it would be able to show a receipt.

[ganymedio]

Good call, offline mode removed, connectivity now required. Your signed-tx handover idea is in Future Potential (needs a return channel, so not v1).

[Primata]

Verified this against live Movement state and the movementlabsxyz/aptos-core framework fork rather than reading it on its own terms. Most of it holds up unusually well — flagging only the three things that require a change.

Checked and correct, so nobody re-litigates them:

Claim	Result
0xa holds ObjectCore + Metadata + auto-created Account (authkey 0x00…0a), 999394914 octas stranded	Exact, to the digit
Chain IDs 126 / 250	Confirmed against both public endpoints
Gas floor: min_transaction_gas_units 2760000 / scaling 50000	Confirmed — 55.2, so ~56
All five entry-function signatures in the selection table	All confirmed against mainnet ABIs
coin::balance = CoinStore + FA store	Confirmed (coin.move:671)
coin_balance is inline fun, not callable	Confirmed — absent from the module ABI
migrate_coin_store_to_fungible_store takes no &signer (OQ#3d)	Confirmed

One free addition: 0xa also holds a stranded CoinStore<…::rushi_coin::RushiCoin> with 10000 units. Two independent parties have lost funds at that address, which strengthens the object-address fixture beyond what the draft claims.

The three blocking items are inline at lines 188, 220, and 399. The first is the significant one — it is a single inverted fact about coin::withdraw that the migration pre-step, Open Question #3, a Risks row, and a Testing row all rest on. Correcting it removes a substantial amount of the machinery, including the two-confirmation payment flow.

[Primata]

Blocking — this is inverted for Movement's framework fork, and it's load-bearing.

I checked movementlabsxyz/aptos-core. coin::withdraw<CoinType> drains CoinStore first, then tops up from the FA store:

// coin.move — calculate_amount_to_withdraw
let coin_balance = coin_balance<CoinType>(account_addr);   // CoinStore balance
if (coin_balance >= amount) {
    (amount, 0)                          // entirely from CoinStore
} else {
    (coin_balance, amount - coin_balance)  // CoinStore, then FA remainder
}

The CoinStore branch then does extract(&mut coin_store.coin, coin_amount_to_withdraw) after assert!(!coin_store.frozen), and the remainder goes through primary_fungible_store::withdraw and is merged. coin::deposit likewise prefers CoinStore when one exists (coin.move:863). Neither path is behind a feature flag.

Three downstream claims fail with it:

Line 194 — "transfer_coins<CoinType> MUST NOT be used. It withdraws from the FA store, so it fails when the payer's balance is in CoinStore<C>." The opposite is true. aptos_account::transfer_coins → coin::withdraw spends a residual CoinStore natively and can span both stores in a single transaction. It is the entry function that solves the problem it is being banned for. (The EACCOUNT_DOES_NOT_ACCEPT_DIRECT_COIN_TRANSFERS objection is real — aptos_account.move:132 — but that is a much narrower reason than "it fails.")

Line 195 — "A residual legacy balance requires a migration transaction first." Not a requirement. It is one option among several.

Line 497 (Open Question #3) — "Note what is not an option: using transfer_coins<C>… It withdraws from the FA store and fails identically. So some migration must happen." That premise is what makes OQ#3 look unanswerable, and it is false. Much of the question dissolves once transfer_coins is back on the table.

Worth being precise about what survives: the migration concern is real for the path the MIP actually selects. transfer_fungible_assets → primary_fungible_store::withdraw has no CoinStore fallback, so it does fail on a residual legacy balance. So the current draft picks the entry function that fails on residual CoinStore and forbids the one that doesn't, on a stated reason that doesn't hold.

Suggested resolution. Re-derive the selection table against the fork, then decide transfer_coins on its actual tradeoff — it handles split balances in one transaction, at the cost of the DirectTransferConfig abort path and a type argument. If it wins for paired assets, this removes the migration pre-step from the flowchart, the MUST on line 195, the balance-location detection on line 197, a Risks row, a Testing row, and most of OQ#3 — along with the two-confirmation payment flow, which is the part of the design that reads as heaviest.

I'd rather see the section rebuilt on verified fork behavior than patched claim by claim; the rest of the document's chain facts held up well under checking, so this looks like one upstream-Aptos reading that propagated.

[ganymedio]

Confirmed against the fork and rebuilt the section. transfer_coins is now selected for paired assets with a residual CoinStore; migration pre-step, two-confirmation flow, and OQ#3 removed.

[Primata]

Blocking — true for upstream Aptos, not for Movement as currently configured.

Movement's fork branches here, where upstream does not:

// aptos_account.move — public entry fun transfer
if (features::operations_default_to_fa_apt_store_enabled()) {
    fungible_transfer_only(source, to, amount)          // the unchecked path
} else {
    if (!coin::is_account_registered<AptosCoin>(to)) {
        coin::register<AptosCoin>(&create_signer(to));
    };
    coin::transfer<AptosCoin>(source, to, amount)       // legacy coin path
}

That gate is OPERATIONS_DEFAULT_TO_FA_APT_STORE, feature 65 (features.move:555). I read the 0x1::features::Features bitmap on both networks:

Flag	Mainnet	Testnet
64 NEW_ACCOUNTS_DEFAULT_TO_FA_APT_STORE	false	false
65 OPERATIONS_DEFAULT_TO_FA_APT_STORE	false	false

So the else branch is what executes today: MOVE routes through coin::transfer<AptosCoin> → coin::withdraw, which does check frozen and does read CoinStore. The sentence as written describes a path that is not currently active.

This matters in both directions. A wallet built on the drafted text is wrong now; a wallet built on current behavior breaks whenever flag 65 is enabled. Since the MIP's whole premise is that wallet-side dispatch absorbs framework change, this is exactly the kind of transition it should name rather than assume.

Suggested resolution. State the behavior as flag-conditional, note that 65 is currently disabled on both Movement networks, and make the conclusion — "wallets MUST NOT route any asset other than MOVE through aptos_account::transfer" — rest on the reasoning rather than on the unchecked implementation, since it holds under both branches.

[ganymedio]

Confirmed, including the flag reads. Now flag-conditional with the current on-chain state noted.

[Primata]

Blocking (small) — this asserts the wrong feature flag.

Flag 15 is STRUCT_CONSTRUCTORS:

// move-stdlib/sources/configs/features.move:178-181
/// Whether struct constructors are enabled
/// Lifetime: transient
const STRUCT_CONSTRUCTORS: u64 = 15;

It has nothing to do with Object<T> entry arguments. It is enabled on Movement mainnet and testnet, so this test passes today — while asserting nothing about the property it claims to protect. A green check that cannot fail for the stated reason is worse than no check, because it will be read as coverage.

Suggested resolution. Either identify the flag that actually gates Object<T> as an entry-function argument and assert that one, or drop the assertion. If the real concern is that transfer_fungible_assets takes Object<Metadata>, a direct test — build and simulate that call against the configured network — proves the capability end to end without depending on a flag number that may be renumbered.

[ganymedio]

Implemented the direct build-and-simulate test.

[ganymedio]

Verified this against live Movement state and the movementlabsxyz/aptos-core framework fork rather than reading it on its own terms. Most of it holds up unusually well — flagging only the three things that require a change.

Checked and correct, so nobody re-litigates them:

Claim Result
0xa holds ObjectCore + Metadata + auto-created Account (authkey 0x00…0a), 999394914 octas stranded Exact, to the digit
Chain IDs 126 / 250 Confirmed against both public endpoints
Gas floor: min_transaction_gas_units 2760000 / scaling 50000 Confirmed — 55.2, so ~56
All five entry-function signatures in the selection table All confirmed against mainnet ABIs
coin::balance = CoinStore + FA store Confirmed (coin.move:671)
coin_balance is inline fun, not callable Confirmed — absent from the module ABI
migrate_coin_store_to_fungible_store takes no &signer (OQ#3d) Confirmed
One free addition: 0xa also holds a stranded CoinStore<…::rushi_coin::RushiCoin> with 10000 units. Two independent parties have lost funds at that address, which strengthens the object-address fixture beyond what the draft claims.

The three blocking items are inline at lines 188, 220, and 399. The first is the significant one — it is a single inverted fact about coin::withdraw that the migration pre-step, Open Question #3, a Risks row, and a Testing row all rest on. Correcting it removes a substantial amount of the machinery, including the two-confirmation payment flow.

@Primata thanks, re-requested review.

[Primata]

This is a careful spec. The parts I tried hardest to break hold up: atomic-unit amounts with an on-chain decimals cross-check removes producer-stated scale from the trust set; keeping the entry function out of the URL means a card stamped today survives the coin-to-FA migration; and the object-address check tests for ObjectCore presence rather than Account absence, which is the subtle version and the correct one. The security model is stated honestly rather than overclaimed — "substitution of an entire request by an attacker controlling the delivery channel is not defended against" is the right admission, and it's what makes the confirmation-screen requirements normative rather than advisory.

I verified both normative chain-ID constants against live nodes, since a wrong one would make every conforming wallet reject every request:

mainnet  chain_id = 126   (MIP says 126) ✓
testnet  chain_id = 250   (MIP says 250, "Bardock") ✓

Incidentally that corroborates something from another review this week: keyless-playground documents its testnet as "Movement Porto, chain id 250", and this MIP naming 250 as Bardock suggests that label is stale.

My one substantive concern is that the browser-extension transport is the least specified binding, and it's the one where the reference implementation went wrong. Details inline, with proposed normative text. Two drafting nits alongside it.

Marking this as changes-requested rather than a comment because the fix is normative text that should land before Draft → Last Call, not a discussion thread — but it's a small addition to an otherwise solid document.

[Primata]

[P2] The browser-extension binding authorizes a surface it doesn't constrain.

Every other binding in this section carries requirements. Android gets a MUST about declaring only the scheme, with the reason (opaque URIs, filters with host/path fail silently). NFC gets the TNF, the type, the identifier code and tag-capacity guidance. The browser-extension binding gets one sentence with a MAY and no constraints — and it's the binding that puts the parser behind an entry point on every page the user visits.

That gap isn't theoretical. I reviewed the reference implementation this MIP names — MoveIndustries/motion-wallet#132 — and both defects I found live precisely in this unconstrained space:

1. No user-activation check. The content script listens for click without testing event.isTrusted, so any page can synthesize a click on a movement: anchor at load and originate a payment request with no user interaction at all.
2. A single pending-request slot, last-write-wins. A background tab can overwrite a request the user legitimately initiated, so the confirmation screen renders a recipient they never chose — while they do remember starting a payment.

Both matter because this MIP's security model rests entirely on the confirmation screen. That screen defends what it renders; it cannot defend against being reached by a request the user never initiated, or against the request being swapped between initiation and display.

Suggest two normative additions here:

A browser-extension wallet intercepting movement: link activation MUST require a genuine user activation for the interception (e.g. a trusted event); a request originated without user interaction MUST be ignored.

A pending request MUST NOT be silently replaced by a later one. A wallet that holds at most one pending request MUST discard the later request rather than the earlier, or MUST identify requests so the payer confirms the one they initiated. The origin that delivered the request MUST be rendered on the confirmation screen.

That third clause matters independently of the extension case: the confirmation-screen section specifies what to render about recipient, asset, amount and network, but not where the request came from. For any in-page binding that provenance exists, and it's the payer's main signal that the request is the one they just clicked.

[Primata]

[P3] expires has no lower bound, and the spec doesn't say what a wallet does with an implausible one.

"MUST set the transaction's expiration_timestamp_secs to no later than expires" is well drafted — "no later than" leaves room for the wallet's own cap, so a request expiring in 2099 doesn't produce a transaction the VM rejects for exceeding its maximum future expiry. That's the right shape.

What's unstated is the other end. A request expiring two seconds from now is valid per the grammar and passes the "reject if past" rule, but will fail submission after the user confirms — a payment that looks fine, gets authorized, then dies, with the failure landing after the user acted rather than before.

Worth a SHOULD that a wallet reject or warn when expires leaves insufficient time to confirm and submit.

[Primata]

[P3] Grammar and prose disagree on chain-id, and the case rule is ambiguous for percent-encoding.

Two small drafting points:

• chain-id = 1*3DIGIT ; 0-255 — the ABNF admits 999, and the range lives only in the comment and the prose. ABNF can't express numeric ranges, so that's unavoidable, but it's worth an explicit sentence that the grammar is permissive and the u8 range check is a separate normative step. An implementer working from the grammar alone produces a parser that accepts @999.
• "Hex is lowercase. A wallet MUST reject uppercase or mixed-case hex" reads as applying to all hex in the URL, but percent-encoding conventionally uses uppercase digits (%2F), and the sci production explicitly permits E. Worth scoping the rule to addresses — e.g. "hex in long-address, special-address and asset-value is lowercase" — so nobody rejects %2F or 1.5E8.

[ganymedio]

Closing this as we are likely going with a third party solution rather than building this in-house.