As discussed offline, this approach is fine for now - but in production, we'll probably have to re-work this as loading the full account into memory may become prohibitively expensive. The two driving factors of this would be:

• GER storage map. This currently has un-bounded growth. If we do come up with a strategy to cap the growth somehow, then this may not be as big of an issue.
• CLAIM note nullifier map (once CLAIM notes are re-oriented toward the bridge account). Here too, if we find a way not to store all note nullifiers in the account, the bridge account size would likely be pretty small.

If the bridge account does grow in size over time, the alternative way to handle these types of methods would be on the client wrapper and to use the StorageReader to read specific information from the database as needed.

Originally posted by @bobbinth in #2562