Post

CodeMultiversX
CodeMultiversX@CodeMultiversX·
Meet the Tech: Async Calls from Contracts 🧩 The protocol-level mechanism that lets one MultiversX contract call another, even when they live on different shards. Cross-shard calls are asynchronous by design — there's no synchronous return across the metachain. The framework gives you a typed surface over the async semantics. Initiate with async_call_and_exit, receive the response in a #[callback]. 💡 🧵
CodeMultiversX tweet media
English
3
20
86
5.8K
CodeMultiversX
CodeMultiversX@CodeMultiversX·
How it works: self.tx() .to(&other_contract) .typed(OtherProxy) .do_work(arg) .with_callback(self.callbacks().on_work_done()) .async_call_and_exit(); The calling contract dispatches the call and exits. When the target contract responds, the protocol routes the result back, and the framework invokes the registered callback. #[callback] fn on_work_done(&self, #[call_result] result: ManagedAsyncCallResult) { match result { ManagedAsyncCallResult::Ok(value) => { /* success path */ } ManagedAsyncCallResult::Err(err) => { /* failure path */ } } }
English
1
1
22
188
CodeMultiversX
CodeMultiversX@CodeMultiversX·
The pattern that makes it broadly useful: three terminal operations, three use cases. Same builder, different async semantics: self.tx()...async_call_and_exit() // dispatches, exits, callback runs on response self.tx()...transfer_execute() // fire-and-forget, no callback, value plus function call self.tx()...sync_call() // same-shard only, returns immediately Pick by what you need from the callee: a typed response (async_call_and_exit), a side effect (transfer_execute), or a direct value when the call doesn't cross shards (sync_call).
English
1
1
12
135
Paylaş