-Currently there isn't any analogue. However, you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out programming and call, static_call and delegate_call. +Yes, starting with SDK version 0.7.0, the Router trait supports both `fallback` and `receive` methods, similar to their Solidity counterparts. The `fallback` method is called when a transaction has calldata that doesn't match any defined function, while the `receive` method is called when a transaction has empty calldata. You can find more information in Fallback and receive functions.
- +For older SDK versions (pre-0.7.0), you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out programming and call, static_call and delegate_call.
diff --git a/arbitrum-docs/stylus/reference/rust-sdk-guide.md b/arbitrum-docs/stylus/reference/rust-sdk-guide.md index 18120d4cde..af17e22a7d 100644 --- a/arbitrum-docs/stylus/reference/rust-sdk-guide.md +++ b/arbitrum-docs/stylus/reference/rust-sdk-guide.md @@ -331,6 +331,39 @@ sol_storage! { } ``` +### Fallback and receive functions + +Starting with SDK version 0.7.0, the [`Router`](https://docs.rs/stylus-sdk/latest/stylus_sdk/abi/trait.Router.html) trait supports the `fallback` and `receive` methods, which work similar to their Solidity counterparts: + +- [`fallback`](https://docs.rs/stylus-sdk/latest/stylus_sdk/abi/trait.Router.html#tymethod.fallback): This method is called when a transaction is sent to the contract with calldata that doesn't match any function signature. It serves as a catch-all function for contract interactions that don't match any defined interface. + +- [`receive`](https://docs.rs/stylus-sdk/latest/stylus_sdk/abi/trait.Router.html#tymethod.receive): This method is called when a transaction is sent to the contract with no calldata (empty calldata). It allows the contract to receive ETH. + +Here's an example implementation: + +```rust +#[public] +impl Contract { + // Automatically called when transaction has calldata that doesn't match any function + #[fallback] + #[payable] + pub fn fallback(&mut self, calldata: Vec\nAll languages are compiled to WASM for them to be able to work with Stylus. So it just needs to verify that the produced WASM programs behave as they should inside the new virtual machine.\n
\n\n\n\n
\n\n","key": "how-does-stylus-manage-security-issues-in-smart-contracts-when-interacting-with-so-many-different-languages"}, -{"question": "Is there any analogue of the fallback function from Solidity in the Rust Stylus SDK?","answer": "\nCurrently there isn't any analogue. However, you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out programming and call, static_call and delegate_call.\n
\n\n\n\n
\n\n","key": "is-there-any-analogue-of-the-fallback-function-from-solidity-in-the-rust-stylus-sdk"}, +{"question": "Is there any analogue of the fallback function from Solidity in the Rust Stylus SDK?","answer": "\nYes, starting with SDK version 0.7.0, the Router trait supports both `fallback` and `receive` methods, similar to their Solidity counterparts. The `fallback` method is called when a transaction has calldata that doesn't match any defined function, while the `receive` method is called when a transaction has empty calldata. You can find more information in Fallback and receive functions.\n
\n\n\nFor older SDK versions (pre-0.7.0), you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out programming and call, static_call and delegate_call.\n
\n\n\n\n
\n\n","key": "is-there-any-analogue-of-the-fallback-function-from-solidity-in-the-rust-stylus-sdk"}, {"question": "Why are constructors not yet supported for Stylus contracts?","answer": "\nConstructors use EVM bytecode to initialize state. While one could add EVM bytecode manually to their Stylus deployment, we don't allow WASM execution in the constructor so there's no way to express this in the SDK.\n
\n\n\nWe're working on models that will make init easier, so there might be better solutions available in the future. For now, we suggest calling an init method after deploying.\n
\n\n\n\n
\n\n","key": "why-are-constructors-not-yet-supported-for-stylus-contracts"}, {"question": "Is it possible to verify Stylus contracts on the block explorer?","answer": "\nCurrently it is not possible to verify contracts compiled to WASM on the block explorer, but we are actively working with providers to have the verification process ready for when Stylus reaches mainnet-ready status.\n
\n\n\n\n
\n\n","key": "is-it-possible-to-verify-stylus-contracts-on-the-block-explorer"}, {"question": "Do Stylus contracts compile down to EVM bytecode like prior other attempts?","answer": "\nNo. Stylus contracts are compiled down to WASM. The user writes a program in Rust / C / C++ which is then compiled down to WebAssembly.\n
\n\n\n\n
\n\n","key": "do-stylus-contracts-compile-down-to-evm-bytecode-like-prior-other-attempts"},