A programming language for writing applications that run on a shared ledger, with resources and ownership rules built into the language. It is designed for safe handling of digital assets and transaction logic, so the code itself helps enforce state changes and limits how values can be copied or discarded.
How Move Uses Resource Semantics
Move is designed around resources, which are values the language treats as non-copyable and non-droppable by default. That choice makes ownership part of the type system, so the compiler can help prevent accidental duplication, loss, or misuse of ledger state.
This matters because shared-ledger applications often represent assets, permissions, and other stateful objects that must move exactly once through a transaction flow. In Move, the language itself becomes part of the safety boundary, reducing reliance on informal developer discipline alone.
Why Move Is Different From Conventional Smart-Contract Languages
Many general-purpose languages allow values to be copied freely unless the developer adds guardrails manually. Move takes the opposite approach, treating asset-bearing state as a special category that must be transferred explicitly and safely.
That design makes the language closer to a policy engine for state changes than a simple syntax for business logic. It helps ensure that ledger updates are deliberate, auditable, and constrained by rules the compiler can enforce before code is deployed.
Ownership, State Change, and Transaction Safety
Move’s ownership model is especially valuable when a program must represent balances, tokens, or other digital assets with strict lifecycle rules. Because resources cannot be silently duplicated or discarded, the language reduces whole classes of bugs that would otherwise create inconsistent state or unintended asset movement.
It also encourages developers to encode invariants directly into the program structure. Instead of relying only on runtime checks, the language can rule out invalid paths earlier, which is important in environments where erroneous state transitions may be irreversible.
Where Move Fits in Shared-Ledger Development
Move is best understood as a language for constrained, stateful computation on ledger systems, not as a general-purpose application language with optional safety features. Its model is suited to environments where asset integrity, explicit transfer semantics, and predictable state transitions are central requirements.
That makes it useful for financial logic, token systems, and other ledger-native applications where the correctness of ownership and transfer behavior matters as much as the business rules themselves. The practical benefit is that developers can express those constraints in the language rather than bolting them on afterward.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS, SLSA and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Move resources often represent protected asset or authority state that must not be copied or lost. |
| Recommendation — Manage resource-bearing secrets and authority material so transfers, rotation, and revocation stay controlled. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Move’s resource semantics shape how safe state transitions are designed and verified in application logic. |
| Recommendation — Design stateful logic so invalid duplication or destruction paths are rejected by the language model and tests. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Move programs rely on trustworthy build and deployment flows for ledger code integrity. |
| Recommendation — Verify build provenance and deployment integrity for ledger programs before they reach production. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Is Protected | Move is about preserving the integrity of stored ledger state and asset representations. |
| Recommendation — Protect ledger state so asset records and transaction data remain intact and controlled. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org