I think that this namespace is confusing. Is it referring cryptography, cryptocurrency, or something else... what do you think about changing this name to auth?

This comment explains something, but to be really helpful it needs to be extended. Please explain what is the purpose of this function and use full sentences (starting with uppercase letter, ending with period) instead of sequences of words.

once an empty string is returned we should verify the state

After some time this info makes sense, but it is inconsistent with the first part and that makes it more confusing. The first part of this comment refers to the function in third person, so we need to be consistent here and write something like: When this function returns an empty string, we should....
And the last part: who are we. Please be more specific here. Is it a client? Or is it a process in the service? Or something completely different.

Overall we should try to write comments so that a reader does not need to have deep knowledge to understand them.

By the way, what are the thread-safety guarantees an implementation should provide? Are we using this code from multiple threads, or do we expect to have thread_local instances? It would really help if either a summary or this comment explained how this class should be used (if we want to have a single instance, a thread_local instance or a dedicated instance for every auth session). My guess is that the third option would be the best as it will make state management the least complicated.

Is this manager used for a single connection? Or do we expect it to handle multiple connections?

My intuition is that we can take a different approach to make this more maintainable and readable. So when we start auth process we should determine if we want to use Pake or wallet, then create a concrete auth manager, store it as an instance variable and forward all the traffic to it. By doing that we would avoid having method-specific code in AuthenticationManager which would make the code simpler and more open to extension.

I suggested a different approach in one comment (you can find advantages there). Instead of having two different authentication manager, you could have only one, specific and forward all the calls to it.

I don't think so. Even when two threads don't access a resource at the same time, we need some synchronization to let one thread know the current state of that resource. The simplest scenario which demonstrates the issue is when one thread modifies a resource in CPU register which isn't saved to memory until necessary. When the second thread accesses this resource, it is read from memory where an outdated value is stored. The only way of introducing "happens before" relationship is by synchronization, which can be achieved by e.g. using atomic values.

Can we change this link to https://en.cppreference.com/w/cpp/language/memory_model#Threads_and_data_races? The C++ reference seems like a better source

Does grpc enforce this formatting?

Shouldn't we also make this atomic?

Shouldn't the authenticationType always be PAKE? I guess it doesn't make much sense to have this as a constructor argument - we should always return PAKE in getAuthenticationType, right?