diff --git a/cli/node/README.md b/cli/node/README.md
index 82756c7..5d56f36 100644
--- a/cli/node/README.md
+++ b/cli/node/README.md
@@ -68,6 +68,9 @@ when running the coordinator in sync mode
   monitor the size of the folder to avoid running out of space.
 - The node requires a PostgreSQL database.  The parameters of the server and
   database must be set in the `PostgreSQL` section.
+- The node requires a web3 RPC server to work.  The node has only been tested
+  with geth and may not work correctly with other ethereum nodes
+  implementations.
 
 ## Building
 
diff --git a/config/config.go b/config/config.go
index 77807f7..419617f 100644
--- a/config/config.go
+++ b/config/config.go
@@ -299,7 +299,8 @@ type Node struct {
 	} `validate:"required"`
 	PostgreSQL PostgreSQL `validate:"required"`
 	Web3       struct {
-		// URL is the URL of the web3 ethereum-node RPC server
+		// URL is the URL of the web3 ethereum-node RPC server.  Only
+		// geth is officially supported.
 		URL string `validate:"required"`
 	} `validate:"required"`
 	Synchronizer struct {
diff --git a/coordinator/coordinator.go b/coordinator/coordinator.go
index a5a60ed..29e2c65 100644
--- a/coordinator/coordinator.go
+++ b/coordinator/coordinator.go
@@ -1,3 +1,43 @@
+/*
+Package coordinator handles all the logic related to forging batches as a
+coordinator in the hermez network.
+
+The forging of batches is done with a pipeline in order to allow multiple
+batches being forged in parallel.  The maximum number of batches that can be
+forged in parallel is determined by the number of available proof servers.
+
+The Coordinator begins with the pipeline stopped.  The main Coordinator
+goroutine keeps listening for synchronizer events sent by the node package,
+which allow the coordinator to determine if the configured forger address is
+allowed to forge at the current block or not.  When the forger address becomes
+allowed to forge, the pipeline is started, and when it terminates being allowed
+to forge, the pipeline is stopped.
+
+The Pipeline consists of two goroutines.  The first one is in charge of
+preparing a batch internally, which involves making a selection of transactions
+and calculating the ZKInputs for the batch proof, and sending these ZKInputs to
+an idle proof server.  This goroutine will keep preparing batches while there
+are idle proof servers, if the forging policy determines that a batch should be
+forged in the current state.  The second goroutine is in charge of waiting for
+the proof server to finish computing the proof, retreiving it, prepare the
+arguments for the `forgeBatch` Rollup transaction, and sending the result to
+the TxManager.  All the batch information moves between functions and
+goroutines via the BatchInfo struct.
+
+Finally, the TxManager contains a single goroutine that makes forgeBatch
+ethereum transactions for the batches sent by the Pipeline, and keeps them in a
+list to check them periodically.  In the periodic checks, the ethereum
+transaction is checked for successfulness, and it's only forgotten after a
+number of confirmation blocks have passed after being successfully mined.  At
+any point if a transaction failure is detected, the TxManager can signal the
+Coordinator to reset the Pipeline in order to reforge the failed batches.
+
+The Coordinator goroutine acts as a manager.  The synchronizer events (which
+notify about new blocks and associated new state) that it receives are
+broadcasted to the Pipeline and the TxManager.  This allows the Coordinator,
+Pipeline and TxManager to have a copy of the current hermez network state
+required to perform their duties.
+*/
 package coordinator
 
 import (
diff --git a/node/node.go b/node/node.go
index 4342252..3133f41 100644
--- a/node/node.go
+++ b/node/node.go
@@ -1,3 +1,18 @@
+/*
+Package node does the initialization of all the required objects to either run
+as a synchronizer or as a coordinator.
+
+The Node contains several goroutines that run in the background or that
+periodically perform tasks.  One of this goroutines periodically calls the
+`Synchronizer.Sync` function, allowing the synchronization of one block at a
+time.  After every call to `Synchronizer.Sync`, the Node sends a message to the
+Coordinator to notify it about the new synced block (and associated state) or
+reorg (and resetted state) in case one happens.
+
+Other goroutines perform tasks such as: updating the token prices, update
+metrics stored in the historyDB, update recommended fee stored in the
+historyDB, run the http API server, run the debug http API server, etc.
+*/
 package node
 
 import (
diff --git a/synchronizer/synchronizer.go b/synchronizer/synchronizer.go
index 3a7e009..17e722e 100644
--- a/synchronizer/synchronizer.go
+++ b/synchronizer/synchronizer.go
@@ -1,3 +1,35 @@
+/*
+Package synchronizer synchronizes the hermez network state by querying events
+emitted by the three smart contracts: `Hermez.sol` (referred as Rollup here),
+`HermezAuctionProtocol.sol` (referred as Auction here) and
+`WithdrawalDelayer.sol` (referred as WDelayer here).
+
+The main entry point for synchronization is the `Sync` function, which at most
+will synchronize one ethereum block, and all the hermez events that happened in
+that block.  During a `Sync` call, a reorg can be detected; in such case, uncle
+blocks will be discarded, and only in a future `Sync` call correct blocks will
+be synced.
+
+The synchronization of the events in each smart contracts are done
+in the methods `rollupSync`, `auctionSync` and `wdelayerSync`, which in turn
+use the interface code to read each smart contract state and events found in
+"github.com/hermeznetwork/hermez-node/eth".  After these three methods are
+called, an object of type `common.BlockData` is built containing all the
+updates and events that happened in that block, and it is inserted in the
+HistoryDB in a single SQL transaction.
+
+`rollupSync` is the method that synchronizes batches sent via the `forgeBatch`
+transaction in `Hermez.sol`.  In `rollupSync`, for every batch,  the accounts
+state is updated in the StateDB by processing all transactions that have been
+forged in that batch.
+
+The consistency of the stored data is guaranteed by the HistoryDB: All the
+block information is inserted in a single SQL transaction at the end of the
+`Sync` method, once the StateDB has been updated.  And every time the
+Synchronizer starts, it continues from the last block in the HistoryDB.  The
+StateDB stores updates organized by checkpoints for every batch, and each batch
+is only accessed if it appears in the HistoryDB.
+*/
 package synchronizer
 
 import (