e-money journal

Today I started poking around with e-money. For those who have never heard of it: it is crypto money, and is behind European stablecoins like eEUR, eCHF, eSEK, eNOK, eDKK. Here’s the project roadmap.

Since this is a largely tech blog, I don’t intend to go into financial & other social aspects of crypto money in general & e-money in particular. This (forever-wip) post is only intended as an “informal diary” noting down what I’ve learned while diving into this project. I’ll also be upfront and state that my 1st intention is to successfully run a validator node for the e-money blockchain.

I also intend to write this post/series for myself and other application developers / DevOps engineers already having basic blockchain knowledge, and so I won’t be explaining terms and definitions from the ground up. I’m happy to point you to resources where you may learn more, so if anything here catches your interest & curiosity, please feel free to leave a comment.

Now without any further ado, I’ll start the (very draft & blunt) journal. From this point on, you’ll find fewer of the English fine-tuned paragraphs, and more of cryptic scripts written in programming languages.

All info below is standing Nov 2021 (except otherwise noted)


If using cosmovisor, you may also specify the cosmovisor/ directory under the home directory of the cosmos project, e.g. ~/.emd/cosmovisorread more here

emd config

Assuming we’re using the default emd homedir (~/.emd), then

  • The main config file location is at the location: ~/.emd/config/config.toml
  • The app config file location is at the location: ~/.emd/config/app.toml
  • The client config file location is at the location: ~/.emd/config/client.toml

The cli to show the config: emd config – so yes, if you enter a value for e.g. the chain-id property in the client config file (mentioned above), its value will reflect as such when you run emd config

When running emd, specifying the homedir for emd itself and for cosmovisor are 2 different things, and should be done separately, e.g.

DAEMON_HOME=/opt/emd/emoney-3/.emd/ cosmovisor config --home /opt/emd/emoney-3/.emd/

As seen from the above command:

  • DAEMON_HOME=/opt/emd/emoney-3/.emd/ : this sets the homedir for cosmovisor
  • --home /opt/emd/emoney-3/.emd/ : this sets the homedir for emd itself
  • cosmovisor config : this is just the command being run (via cosmovisor) and can be anything else (e.g. start or help, so on & so forth)


emd unsafe-reset-all can be useful when your configuration change doesn’t take effect. Of course, as the name implies, this is a dangerous operation, and should only be used as a last resort.

binary Upgrades in practice

If we install 1.1.3 and then join lilmermaid-16 & sync with its genesis, at some point we’ll run into this panic:

DAEMON_HOME=$HOME/.emd cosmovisor start --x-crisis-skip-assert-invariants --log_level warn
5:35PM ERR BINARY UPDATED BEFORE TRIGGER! UPGRADE "upgrade-plan-1" - in binary but not executed on chain
panic: BINARY UPDATED BEFORE TRIGGER! UPGRADE "upgrade-plan-1" - in binary but not executed on chain

This is because (obviously) our binary was “upgraded” way before it was supposed to be. The trick is to do exactly as instructed: putting the correct binaries in the correct directories managed by cosmovisor. Then start the process again (with cosmovisor – of course) and let things taken care of automatically for you.

5:45PM ERR Error dialing peer err="dial tcp i/o timeout" module=p2p
5:45PM ERR UPGRADE "upgrade-plan-1" NEEDED at height: 12670:
starting to take backup of data directory at time 2021-11-08 17:45:01.563909605 +0000 UTC m=+5.306000545backup saved at location: /home/ubuntu/.emd/data-backup-2021-11-8, completed at time: 2021-11-08 17:45:02.384214233 +0000 UTC m=+6.126305179
time taken to complete the backup: 820.304634ms5:45PM ERR dialing failed (attempts: 1): dial tcp connect: connection refused addr={"id":"98171ae2eb5d58dfad7d5b504427ab5b6b6d0d26","ip":"","port":26656} module=pex

So, apparently cosmos blockchain applications have binary version management done on-chain itself. This feature probably was initially introduced to prevent hard forks.

Alternatively, I also succeeded at doing “drop-in replacement” upgrades. This means we may just build out a new binary (or even more conveniently, copy the pre-built binary from emd v1.1.4 onwards) and place it in wherever the existing emd executable is installed. As usual, be very explicit about the DAEMON_HOME and --home options that apply when you run your executable.

is that All?

For now, yes. I’ll update this post if/when I find more noteworthy stuff. Hope this helps. Cheers!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s