from what I've learned so far, the OCW is designed specifically for executing heavy and time-consuming computations outside of the runtime. As the OCW is not a part of runtime/wasm, I guess the OCW should be able to use crates that depend on the rust std lib.

However, when I'm trying to implement a simple OCW in a pallet lib.rs file like this:

    #[cfg(feature = "std")]
    mod offchain; // module that implements OCW logic and uses external crates that depend on the `std`

    impl<T: Config> Hooks<BlockNumberFor<T>> for Pallet<T> {
        fn offchain_worker(block_number: BlockNumberFor<T>) {

            log::info!("Log message 1");

            #[cfg(feature = "std")]
                log::info!("Log message 2");

then, compiling my node binary as:

cargo build --release --features std

and then, running it as:

./target/release/node --dev

I see only the output "Log message 1" string, and I never see the output with the "Log message 2" string in my console, which probably means my actual OCW implementation in perform_offchain_work() never executes.

Can you help me understand better the design of the OCW and how I can get it working with external crates dependent on std? What I'm doing wrong in my example? Maybe I should provide some extensions to the OCW via custom host functions? Is there any good example for that?

1 Answer 1


I'm not sure why it was designed this way, but I understand how it works.

Perhaps they intended for the OCW to run anywhere since it's part of the WASM blob.

Therefore, everything is compiled into WASM. Although it performs some computational tasks, it's not part of the core runtime. However, it still needs to be compiled into WASM and must adhere to no-std requirements.

And here is a post for more detail.

  • Thank you for the clarification. So, that means the OCW implementation is limited to no_std as it needs to be compiled into WASM. I thought OCW is mostly a part of the outer-node as it is not a part of the core runtime as you mentioned and executes in a separate process. But looks like I was wrong. Commented May 29 at 15:54
  • 1
    Why not just create a separate CLI tool? This would keep the node code simple. Allowing it to run entirely in a STD ENV. It will be more stable and easier to maintain.
    – AurevoirXavier
    Commented May 29 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.