Statefull vs Stateless smart contracts

Hi @fabrice

what are your thoughts on statefull vs stateless smart contracts?

For example the limit order (ARC-0017):

Stateful good things:

• One can list all related txs by querying app id
• Possibility of updates of application

Stateless good things:

• More efficient in algod
• One transaction less (does not need to do app call) (cheaper)
• Less complex code (simple approval tx)
• More legal safe - Noone controls the application - Noone can prevent usage in the US (user by him self is creating the contract)

For the recent hackathons i have submitted the arc0017 indexer and web to place orders, cancel orders, and hit orders

The main question is… Am I missing something why people should use the stateful smart contract or why noone is discussing at arc-0017 - ASA2ASA Stateless orderbook smart contract · Issue #68 · algorandfoundation/ARCs · GitHub ?

I have no checked in details the smart contracts, but indeed for a limit order, stateless (aka smart signature) is sufficient and I agree with the pros you mentioned apart from the legal safety.

You can indeed have the stateful application (aka smart contract) disable updates and get the same legal advantages as stateless.

There are however two other pros of (stateful) smart contracts:

• composability: if you want the DEX to be used by other smart contracts, you cannot easily do it with smart signatures (as smart contracts cannot use smart signatures in inner transactions)
• extensibility: if you need to add a feature that requires state at any point, smart signatures will no more work and you will need to introduce a stateful smart contract.

That is why I usually recommend to focus on (stateful) smart contracts and only use smart signatures (aka stateless smart contracts) in very specific cases.

I thought that inner transactions feature does not limit you to do only app calls…

If you can do 2 grouped inner transactions, you can make arbitrage smart contract which will cost you to execute 2 txs for the first trade, 2 txs for second trade and overhead with the app create tx…

DeFi arbitrage without any risk just profit will lead to minimize the arbitrage profits and algorand price for tx will be the decision point there…

Inner transactions are only allowed when the sender is the “application account” of the smart contract.
You cannot use logicsig/smart signatures.

i thought that primary use case was to interact with other smart contracts… no? you would have to make the app call tx for the other smart contracts where the sender is not the “application account” … no?

what if other smart contracts require the logicsig as one of the group txs?

This case is not supported. Most modern smart contracts do not use logic sigs so this works out well.

Are there any plans to incorporate LogicSigs into inner transactions? @fabrice

There are no plans to add this functionality currently.