Fix the CI badges in README

README.org

@@ -1,7 +1,8 @@
 #+TITLE: Chainweb Data
 #+AUTHOR: Colin
 
-[[https://github.com/kadena-io/chainweb-data/workflows/Build/badge.svg]]
+[[https://github.com/kadena-io/chainweb-data/actions/workflows/ci.yaml/badge.svg]]
+[[https://github.com/kadena-io/chainweb-data/actions/workflows/nix.yml/badge.svg]]
 
 * Table of Contents                                       :TOC_4_gh:noexport:
 - [[#overview][Overview]]
@@ -315,7 +316,7 @@ If the already executed migrations are a prefix (i.e. they were run in the corre
 of the expected migrations, then the rest of the migrations will be executed.
 
 By taking advantage of this alphabetical sorting, ~chainweb-data~ operators can insert custom migrations to be executed at the moment they desire.
-For example, version 2.3.0 of ~chainweb-data~ will have migrations done on top of version 2.2.0, thus having migrations named ~2.2.0.N_...~ (~N>=1~). Creating a custom migration named ~2.3.0.0.N_...~ will guarantee that it'll be executed after the new migrations that come with version 2.3.0 and before the new migrations of future versions, which are guaranteed to have a name greater than ~2.3.0.1_...~. 
+For example, version 2.3.0 of ~chainweb-data~ will have migrations done on top of version 2.2.0, thus having migrations named ~2.2.0.N_...~ (~N>=1~). Creating a custom migration named ~2.3.0.0.N_...~ will guarantee that it'll be executed after the new migrations that come with version 2.3.0 and before the new migrations of future versions, which are guaranteed to have a name greater than ~2.3.0.1_...~.
 Likewise, ~chainweb-data~ operators that run the latest commit
 from the ~master~ branch can also inject their migrations. For example, if the latest commit
 has the last migration named ~2.2.0.1_...~, then their migrations can be named ~2.2.0.1.N_...~.