# Building JAM Services in Rust **URL:** \ **Category:** Tech Talk\ **Created:** [September 26, 2024, 6:16pm UTC](https://forum.polkadot.network/t/building-jam-services-in-rust/10161 "2024-09-26T18:16:08Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![sourabhniyogi](https://avatars.discourse-cdn.com/v4/letter/s/35a633/32.png) [@sourabhniyogi](https://forum.polkadot.network/u/sourabhniyogi)\ **Post date:** [September 26, 2024, 6:16pm UTC](https://forum.polkadot.network/t/building-jam-services-in-rust/10161/1 "2024-09-26T18:16:09Z")
With @koute’s help [here](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513/26), we were able to compile our first JAM service built in Rust into PVM byte code. Woohoo! Amazingly, its nothing more than a “cargo build” and a `polkatool` call. No more hand assembling PVM byte code like its 1964! 😅 😂 🥰 We opened a draft pull request [here](https://github.com/koute/polkavm/pull/176). Check the [README](https://github.com/koute/polkavm/blob/60c055f89195fb48208ce7346599f6a009305c7e/guest-programs/jam-service-fib/README.md) for details. We should be able to prepend a header _soon_ to make this byte code fully GP-compatible/JAM-ready within `polkatool`, enabling JAM implementers to fold Rust-built JAM Services into JAM’s guaranteeing/assuring/auditing/disputes processes. The first few JAM service builders can aggregate JAM Services examples [here](https://github.com/JamBrains/polkavm-examples) showing many of host functions in action in the context of refine-accumulate for multiple languages: Rust _right now_, C/C++ _surely_, Solidity (with [`revive`](https://forum.polkadot.network/t/contracts-on-assethub-roadmap/9513)), and maybe other languages too. ---
**Author:** ![ltfschoen](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ltfschoen/32/3960_2.png) [@ltfschoen](https://forum.polkadot.network/u/ltfschoen)\ **Post date:** [May 25, 2025, 12:10pm UTC](https://forum.polkadot.network/t/building-jam-services-in-rust/10161/2 "2025-05-25T12:10:36Z")
Why did you choose to close that draft pull request? ---
**Author:** ![burdges](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/burdges/32/172_2.png) [@burdges](https://forum.polkadot.network/u/burdges)\ **Post date:** [May 25, 2025, 6:04pm UTC](https://forum.polkadot.network/t/building-jam-services-in-rust/10161/3 "2025-05-25T18:04:41Z")
Just remember, accumulate should never have much CPU time, probably not even enough for a signature verifications. Accumulate should only copy around hashes between the block header(s) and RC state. Anything more than copying hashes is likely to be a poor design, maybe extremely expensive, and probably results in low throughput or stalls. The big deal we market is you can have more than one mutable state root, which is the “actor” model. This matters for smart contract chains like moonbeam because they can shard state to use more core than what’s possible with elastic scaling. If you have a true dApp chain, maybe you want the actor model, but probably you can do better with only one multable state root per chain, plus multiple immutable ones, aka off-chain messaging. Anything with exactly one mutable state root like this should still be considered morally the “parachain model” plus off-chain messaging, although it’d likely worth using the service frameworks to avoid problematic design choices in frame. Internally, another big dal is you can have zero mutable state roots, which allows more “unstopable” system services for elections or DKGs. I donno if zero mutable state roots is ever useful for customer services. ---
**Author:** ![sourabhniyogi](https://avatars.discourse-cdn.com/v4/letter/s/35a633/32.png) [@sourabhniyogi](https://forum.polkadot.network/u/sourabhniyogi)\ **Post date:** [May 25, 2025, 10:00pm UTC](https://forum.polkadot.network/t/building-jam-services-in-rust/10161/4 "2025-05-25T22:00:02Z")
These [services](https://github.com/colorfulnotion/polkavm/tree/dev/services) were just toy experiments for us to understand the refine-accumulate services architecture, and now we know what the point is: _CoreVM and CorePlay programs_ – similar to how applications outnumber OS by 6-8 orders of magnitude, there will be a low need for JAM Services: CoreVM + CorePlay will be enough, and there should only be a few other animals like these. We don’t really want multiple CoreVM OSes, since there is just one thing CoreVM compiles to: PVM. We’ll have a CoreVM service published soon .. and then we will want _not_ lots of new JAM Services but lots of CoreVM programs, and CorePlay programs. We should ready product management around CoreVM/CorePlay and not JAM Services, supported by teams getting linear recompilation in order this summer + fall. ---
**Author:** ![Reparodynamics](https://avatars.discourse-cdn.com/v4/letter/r/45deac/32.png) [@Reparodynamics](https://forum.polkadot.network/u/Reparodynamics)\ **Post date:** [October 30, 2025, 1:32am UTC](https://forum.polkadot.network/t/building-jam-services-in-rust/10161/5 "2025-10-30T01:32:42Z")
Very cool work! 🔥 I’m testing a similar idea called SubReparo — using “Proof-of-Repair” events instead of transactions. Seeing JAM compile Rust this smoothly makes me wonder if repair-validation logic could run as a JAM service. Is the current byte-code interface stable enough to try that?