Semantic Mapping
Neo DevPack for Solidity accepts Solidity syntax and lowers it to Neo N3 contracts. This section splits the EVM-to-Neo behavior map by topic so readers do not have to scan the language, internals, devpack, and standards references on one page.
Reading Path
| Topic | Start Here | Use When |
|---|---|---|
| Execution context | Execution Context | You need msg, tx, block, this, or gasleft() behavior. |
| Types | Types and Values | You are checking how Solidity values become NeoVM stack items or ABI values. |
| Storage | Storage and Mappings | You are using state variables, mappings, arrays, structs, or upgradeable storage. |
| Calls and assets | Calls and Assets | You are porting Ether transfers, address.call, callbacks, or token flows. |
| Syscalls | Syscalls and Devpack | You want to know which Neo syscall or devpack wrapper backs a Solidity construct. |
| Parity | Parity and Limitations | You need to distinguish exact, approximate, warning-only, and unsupported behavior. |
| Standards | Standards Mapping | You are porting ERC/EIP patterns to NEP standards or manifest capabilities. |
| Compiler lowering | Indexed Storage Lowering | You are working on mapping/indexed-storage compiler implementation details. |
Mapping Rule of Thumb
Neo DevPack for Solidity preserves Solidity source compatibility where it can, but the runtime target is Neo N3. Exact mappings compile silently. Approximate mappings compile with diagnostics. Unsupported mappings are rejected or intentionally blocked when Neo cannot provide the EVM security or state semantics.