<p>A state-machine gives you a framework for testing and reasoning about your code. It's generally much easier to think in terms of state machines where transactions are transitions, every transaction is one transition from one state into another, so knowing the initial conditions, you can think about what should be the outcome and test for it.</p>
<p>One &quot;direct drawback&quot; of representing things as state machine is that it forces you to include datums of both inputs you spent but also outputs you send to (since your validator must control the transition goes into the right state). There are cases where you may not want to reveal the datum upfront and obfuscating behind a hash is quite handy.</p>
<p>Another drawback is the maturity / usability of the current state machine framework in PlutusTx. Works well enough for simple scenarios but gets in the way of more complex cases and, adds a non negligible overhead. Yet, implementing a state-machine by hand is relatively easy.</p>

CC BY-SA 4.0
2023-12-01T06:50:14.430Z
Can you provide some example for "gets in the way of more complex cases"?
uhbif19
CC BY-SA 4.0
2022-04-09T05:59:18.240Z
2022-04-09T05:59:18.240Z
KtorZ
<p>Some validator scripts can be implemented with or without state machine. This is a decision that has to be made by the developer.</p>
<p>I wonder what are the pros and cons of using state machine. What factors should be considered when making the decision.</p>

<statemachines>
To use state machine or not to use state machine? This is a question
# To use state machine or not to use state machine? This is a question

(Asked by: username_0 on 2022-04-09)

Some validator scripts can be implemented with or without state machine. This is a decision that has to be made by the developer.

I wonder what are the pros and cons of using state machine. What factors should be considered when making the decision.

**Tags:** statemachines

---

## 1 answers

### Answer by username_1 on 2022-04-09. Score: 2 | Accepted answer

A state-machine gives you a framework for testing and reasoning about your code. It's generally much easier to think in terms of state machines where transactions are transitions, every transaction is one transition from one state into another, so knowing the initial conditions, you can think about what should be the outcome and test for it.

One "direct drawback" of representing things as state machine is that it forces you to include datums of both inputs you spent but also outputs you send to (since your validator must control the transition goes into the right state). There are cases where you may not want to reveal the datum upfront and obfuscating behind a hash is quite handy.

Another drawback is the maturity / usability of the current state machine framework in PlutusTx. Works well enough for simple scenarios but gets in the way of more complex cases and, adds a non negligible overhead. Yet, implementing a state-machine by hand is relatively easy.

> **Comments:**
> **username_2**: Can you provide some example for "gets in the way of more complex cases"?  

---

