diff --git a/LightHouse-addrMap.md b/LightHouse-addrMap.md
index 8116b21..4ce88ab 100644
--- a/LightHouse-addrMap.md
+++ b/LightHouse-addrMap.md
@@ -2,7 +2,7 @@ This is an incomplete, point-in-time, high-level overview of how `LightHouse.add
 
 When Nebula starts, it constructs a single `LightHouse` struct used for the duration of the process. It persists across reloads.
 
-A LigthHouse contains an `addrMap` (`map[iputil.VpnIp]*RemoteList`) mapping all of the VPN IPs it is tracking to their associated underlays. `addrMap` lives for the duration of the process.
+A LightHouse contains an `addrMap` (`map[iputil.VpnIp]*RemoteList`) mapping all of the VPN IPs it is tracking to their associated underlays. `addrMap` lives for the duration of the process.
 
 `RemoteList` structs contains a deduplicated set of addresses (`addrs`) and relays (`relays`) that can be used to talk to a given VPN IP. These two fields are populated by `unlockedCollect` and deduped by `unlockedSort`, based on the `cache` and `hostnameResults` objects).) `RemoteList` entries are deleted by `DeleteVpnIp` when a tunnel is closed or detected dead  (unless the VPN IP is in the static host map - we can't delete these or we wouldn't learn them again until Nebula is reloaded!) They are created on the fly by `unlockedGetRemoteList` if they don't already exist for a given VPN IP, e.g. inside `addStaticRemotes` , `QueryCache`, `addCalculatedRemotes`, `handleHostUpdateInformation`, `handleHostQueryReply`, etc.