Allow invoking ephemeral contracts

[kalepail]

Original discussion on Discord

As far as I’m aware contract code and contract instances must be persistent entries. Would it be possible to allow for these to be temporary entries? I’ve already noticed a few occasions where I’m deploying and invoking an ephemeral contract. Either for a test I really want to execute on mainnet or more legitimately there’s a function I want to run once or at least really infrequently such that redeploying a new contract or wasm later on would be acceptable.

Idk if others feel the same or have additional use cases but here are a few that come to my mind:

• Running tests on mainnet
  • Traditionally this wouldn't be feasible but given we can expire entries running mainnet tests would now be feasible and affordable.
• Single use functions
  • Rather than having to have every contract be reusable and agnostic you could more feasibly and reasonable build single use, special purpose, hard coded contracts that are meant to only execute once. Things like specific agreement or term based transfers. aka escrow.
  • I like the idea that contracts don't have to be businesses but more just actual peer to peer ephemeral special case contracts.

Temporary entries are significantly cheaper than persistent and being able to leverage that for code and contracts I think would incentivize more experimentation and exploration of use cases we've never seen on chain before due to it's typical permanence and subsequent high costs.

[tomerweller]

I agree with what @dmkozh said in the thread:

for truly 'ephemeral' contracts it could be nicer to just upload wasm in a tx that invokes it, i.e do something like 'static' functions
this way you don't write anything at all, and you probably don't care about the contract-owned state

And yes, I think that developers should be able to orchestrate a set of invocations atomically in a simple way without having to upload contracts and think about lifetimes at all.

(Changing the title a bit to match the requirement)

[kalepail]

Reviving this with numbers, since the thread stalled before it had any.

Uploading Wasm on mainnet today, at protocol 27:

	Wasm	Fresh upload
A minimal proxy contract	1,713 B	3.5 XLM
KALE farm	19,492 B	33 XLM
Soroswap router	34,253 B	35 XLM
Blend Fixed V2 pool	57,328 B	86 XLM

~3.5 XLM is the floor for any contract, however trivial, and ~99.9% of it is rent on the instantiated module's in-memory size. The cleanest demonstration is a pair of real transactions from 2026-07-16: the same 28,784-byte Wasm uploaded twice, 29 minutes apart, def6c8e9… for 24.86 XLM and f63118b5… for 0.0147 XLM. Same bytes, same parse, write_bytes: 0 the second time. The fee is buying residency, not work.

For contrast, carrying those same bytes through a transaction and discarding them costs about 0.036 XLM in bandwidth and history, and no transaction can spend more than 0.028 XLM on CPU at any size.

Why I think this is worth doing, and not just a fee complaint.

The floor doesn't make one-shot logic expensive, it makes it categorically absent. Every contract on Stellar today has to be a business — something reused enough to amortize permanent residency in every validator's memory. So we have never seen what Stellar looks like with contracts that are closer to a sentence than a building: a single escrow written for one deal between two parties, settlement logic that exists for one afternoon, a hand-rolled atomic sequence that isn't worth productizing. That isn't a class of thing people tried and abandoned; it's a class of thing nobody has ever been able to try. The 3.5 XLM floor is a tax on experimentation, and it lands hardest on exactly the uses we'd learn the most from.

The agent case sharpens it. Agents composing on-chain actions will generate novel, situation-specific logic constantly, and first-time bytecode can never amortize — every composition pays full freight for 120 days of residency it will use for one ledger. "Deploy a permanent contract first" is not a step that survives in that loop.

One distinction I'd draw that the original thread didn't. There are two goals here and they may want different answers:

• (A) Atomic composition over contracts that already exist. A rich enough router or custom account probably covers this without a protocol change, and honestly multi-op Soroban transactions might be the cleaner fix.
• (B) Executing novel bytecode once. Arbitrary branching that can't be pre-encoded as a DSL, or logic that only exists for one agreement. Nothing addresses this today at any price under the floor.

I care about (B). If (A) gets solved separately I'd still want (B).

On mechanism, @dmkozh's suggestion in this thread still looks like the right one to me — Wasm in the transaction, a reserved export that fires at execution time the way __constructor fires at instantiation, nothing written. Worth noting the pricing precedent already exists: CAP-0065 has upload-then-invoke-in-the-same-ledger paying a full parse under CAP-0054's refined cost model, because the cache only helps in later ledgers. That's the ephemeral shape, already metered.

Temporary CONTRACT_CODE is the smaller delta and would cut rent 240×, but it puts short-lived modules into the global module cache, which seems like the harder thing to justify.

[dmkozh]

For contrast, carrying those same bytes through a transaction and discarding them costs about 0.036 XLM in bandwidth and history, and no transaction can spend more than 0.028 XLM on CPU at any size.

FWIW this example is not valid. Duplicate Wasm upload is a no-op, so you can't measure the CPU costs this way. But in the end the cost will still be orders of magnitude cheaper than the rent cost, so I agree that the overall cost argument stands.

(A) Atomic composition over contracts that already exist. A rich enough router or custom account probably covers this without a protocol change, and honestly multi-op Soroban transactions might be the cleaner fix.

I don't understand what this is trying to say, looks like AI slop to me. But I do think that a lot of use cases can be covered via source sharing and multi-instance contracts.

I'm still skeptical about the original idea concerning temporary generic contract code, as it also requires temporary contract instances, and seems pretty messy w.r.t. lifetimes, module cache etc. If stateless invocations are sufficient, then I think we can just add a host function like call_wasm_fn(wasm, fn_name, args), which will parse and instantiate a VM from the provided Wasm blob, spawn a contract frame, and run the function. The limitation will be that the storage access is prohibited in this frame. This way you can decide how to store the blob yourself: you can pass it in the transaction, or store it in a temp entry etc.

I must point out that this will still be more expensive than the normal transactions (and it has to be more expensive, we don't really want this pattern to be used casually to implement long-lived protocols). But it will indeed be much cheaper than the full-fledged unique contract, when that's relevant.

[kalepail]

I don't really have a dog in the fight on how this gets implemented and more that it allows cheap execution of net new contracts or even just specific functions. Maybe a new WASM type that isn't a whole contract but more just a single function.

Statelessness is fine imo as long as cross contract calls are supported so storage can be read and written just in other persistent "normal" contracts.

Also

looks like AI slop to me

how dare you 😂

[tupui]

For the AI part (not assuming anything or that this could have been AI, just find the comment funny and a good excuse to point this out), maybe a good time now to have a policy. Rustlang just published theirs and people seem to say it's quite good https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ The part about disclosure and creative work is quite good IMO.