@ChihChengLiang When would we want to trigger an update to this public testnet? I can see doing it either on merges to master or on releases. On master merges would lead to more frequent updates but could be unstable/bug riddled, whereas releases will keep things more stable but have less updates.

We could have two different contract/node deployments, one off of master and another off of releases. The unstable master one would be very similar to the internal dev net we have now.

We could also try a hybrid approach, something like:

• Releases deploy contract changes, as well as update stable node(s).
• master merges update unstable node(s)

I'm slightly leaning toward a trigger at release. When we redeploy there are usually minor or trivial bugs to investigate or fix, which might be annoying to fix frequently.

But all the approaches sound good to me.

Rather than managing our dev testnet on a VM, consider as part of this work automating updates to the dev testnet using a CI/CD pipeline as well. Can push updates on merges to master.

If this increases scope too much, break off into another issue.