Alex•

what is a "built-in function" on MultiversX, and why doesn't a token transfer run as a smart contract? quick one, in plain words. on many chains a token is a contract. every balance lives in that contract's storage, and sending the token means calling the contract so it updates its own map. on a sharded chain that design hurts. a popular token contract sits in one shard, so every transfer of it, from every user in every shard, has to pass through that one place. so MultiversX does it the other way. ESDT tokens are native. your balance of a token lives in your own account, next to your EGLD. [ROBERT: confirm wording] moving it is a built-in function: ESDTTransfer, ESDTNFTTransfer, MultiESDTNFTTransfer. they are written in Go, inside the protocol. no WASM instance is started for a plain transfer. what we get from that: - a transfer touches only sender and receiver. the sender's shard debits, the receiver's shard credits. no central contract. - predictable gas from the gas schedule, not whatever the token author wrote. - every token behaves the same. no hidden fee-on-transfer, no surprise hooks in a token contract. the same family covers account actions too: ChangeOwnerAddress, ClaimDeveloperRewards, SetGuardian, SaveKeyValue. the trade-off is real: a token can't run arbitrary code when it moves. if you want that logic, it lives in your own contract and tokens go through it. for me it is the right default. the common path stays native and simple, the custom path is opt-in. you can see it in any transaction's data field: ESDTTransfer@<token>@<amount>.