diff --git a/README.md b/README.md
index b4e9ce7..aa976bb 100644
--- a/README.md
+++ b/README.md
@@ -148,7 +148,7 @@ type Params struct {
     IncludeReceipts          bool
     IncludeTD                bool
     IncludeCode              bool
-    WatchedAddresses         []core.Address
+    WatchedAddresses         []common.Address
 }
 ```
 
@@ -216,7 +216,7 @@ The service also exposes unary RPC endpoints for retrieving the state diff `Stat
 StateDiffAt(ctx context.Context, blockNumber uint64, params Params) (*Payload, error)
 
 // StateDiffFor returns a state diff payload for the specific blockhash
-StateDiffFor(ctx context.Context, blockHash core.Hash, params Params) (*Payload, error)
+StateDiffFor(ctx context.Context, blockHash common.Hash, params Params) (*Payload, error)
 ```
 
 To expose this endpoint the node needs to have the HTTP server turned on (`--http`),
@@ -256,22 +256,20 @@ and `data` contains the bytes for the IPLD block (in the case of all Ethereum IP
 byte encoding of the Ethereum object).
 
 The IPLD objects in this table can be traversed using an IPLD DAG interface, but since this table
-only maps multihash to raw IPLD object it is not particularly useful for searching through the data
-by looking up Ethereum objects by their constituent fields (e.g. by block number, tx
-source/recipient, state/storage trie node path). To improve the accessibility of these objects we
-create an Ethereum [advanced data
+only maps CID to raw IPLD object it is not very suitable for looking up Ethereum objects by their
+constituent fields (e.g. by tx source/recipient, state/storage trie path). To improve the
+accessibility of these objects we create an Ethereum [advanced data
 layout](https://github.com/ipld/specs#schemas-and-advanced-data-layouts) (ADL) by generating
 secondary indexes on top of the raw IPLDs in other Postgres tables.
 
 These secondary index tables fall under the `eth` schema and follow an `{objectType}_cids` naming
 convention.  These tables provide a view into individual fields of the underlying Ethereum IPLD
 objects, allowing lookups on these fields, and reference the raw IPLD objects stored in
-`ipld.blocks` by foreign keys to their multihash keys.  Additionally, these tables maintain the
-hash-linked nature of Ethereum objects to one another. E.g. a storage trie node entry in the
-`storage_cids` table contains a `state_id` foreign key which references the `id` for the
-`state_cids` entry that contains the state leaf node for the contract that storage node belongs to,
-and in turn that `state_cids` entry contains a `header_id` foreign key which references the `id` of
-the `header_cids` entry that contains the header for the block these state and storage nodes were
+`ipld.blocks` by CID.  Additionally, these tables maintain the hash-linked nature of Ethereum
+objects to one another, e.g. a storage trie node entry in the `storage_cids` table contains a
+`state_leaf_key` field referencing the `state_cids` entry for the state trie node of its owning
+contract, and that `state_cids` entry in turn contains a `header_id` field referencing the
+`block_hash` of the `header_cids` entry for the block in which these state and storage nodes were
 updated (diffed).
 
 ### Optimization