Standards and platform references

Each pattern rests on a specific platform mechanism. This maps them to what they govern from a security perspective, and to the clause or behaviour that matters when implementing against them, since most implementation bugs are a rule the code did not honour.

Aptos Improvement Proposals

AIP	Governs	What matters when you implement against it
AIP-112	Resource lock for closure dispatch	On re-entry, reads of the re-entered module’s own resources abort with RUNTIME_DISPATCH_ERROR (major status 4037). The scope is the whole point: values passed to the callback, and resources of other modules, are untouched by it.
AIP-73	Module lock for native dispatch	Stricter than the resource lock: re-entry into an active module through any call is refused. Applies to dispatchable fungible assets and to anything carrying #[module_lock].

Language and platform versions

Feature	Introduced	Security consequence
Function values (closures)	Move 2.2, mainnet in Aptos 1.35	Supplies the dynamic dispatch Move previously lacked, which is what makes reentrancy reachable at all. Captured arguments are fixed at closure-lift time; a stored function value executes whenever it is called, which makes validation-at-creation a time-of-check-to-time-of-use hazard.
Inferred acquires	Move 2.2	The annotation may be omitted. It is still exactly enforced, so it is never wrong, but its presence in source is no longer a signal of what a function touches.
Struct and enum visibility	Move 2.4	A public struct exports compiler-generated pack$ / unpack$ / borrow$ / borrow_mut$ accessors as public API of the defining module. borrow_mut$ grants mutable field access to every module.
Public struct transaction arguments	PUBLIC_STRUCT_ENUM_ARGS	An entry function can receive a caller-constructed struct, so a value’s existence is not evidence of how it was built.

Framework behaviour worth knowing

Mechanism	Governs	What matters
std::mem::swap	Value replacement through &mut	Public, so any callee holding &mut T can substitute a different T. Encapsulation holds; identity does not.
aptos_framework::randomness	On-chain randomness	Reachability from a public function is a compile-time check, overridable in source with #[lint::allow_unsafe_randomness]. A compile-time rule constrains your toolchain, not an arbitrary published module.
0x1::code upgrade policy	Package upgradeability	Three policies: arbitrary, compatible, immutable. Policy may only be strengthened, publishing with arbitrary is rejected, and an immutable package cannot be upgraded, which makes pausing a design requirement rather than a nicety.
Arithmetic	Overflow behaviour	+ - * / abort. << discards high bits silently; an over-wide shift amount aborts.

How the platform-behaviour claims were checked

Source claims were read from aptos-labs/aptos-core at commit 0dfe6f57be955b77180fc799bbfdb8758ab8dfee, not from documentation about it. The files behind the claims above are third_party/move/move-vm/runtime/src/reentrancy_checker.rs (the locks), third_party/move/move-bytecode-verifier/src/ (what is rejected at load), third_party/move/move-binary-format/src/compatibility.rs (upgrade shape rules), aptos-move/aptos-vm-environment/src/prod_configs.rs (production limits), and aptos-move/framework/aptos-framework/sources/code.move (upgrade policy).

Behavioural claims were measured rather than inferred. The abort status a lock produces, and the boundary of what it covers, are asserted by the tests in src/tests/, which fail if the platform stops behaving that way. Run them with aptos move test --language-version 2.4.

src/Move.toml pins the framework dependency to that same commit rather than to a branch, so the samples compile against a fixed revision.

Pin the commit again when re-dating any page: several claims here are version-gated, and a feature flag can change under a page without anything in this repository changing.