We have a set of hosts running replicas of the actual service (ignoring their internal communication topology), and (possibly identical) a set of hosts which are exposed to the Internet and provide some mechanism (e.g. round robin DNS) for letting a client connect to an arbitrary one of them.
A pseudo-vat implements CapTP trivially: it ignores all incoming messages except nonceLocator#lookupSwiss/2. A successful lookup returns a live reference to a presence of the relevant object in one of the replica-vats.
In order to preserve transparency, the pseudo-vat must not support any feature (e.g. incoming 3Descs, WormholeOp, etc.) which would require it to connect to other vats, as then its non-singular nature could be revealed.
The pseudo-vat should be a reasonably simple application of the CapTP-in-E subsystem (if it isn't possible, CapTP-in-E needs to be redesigned).
However, in order to support the 3-vat introduction for the redirected-to live ref, the NonceLocators provided by the replica-vats must be able to accept acceptFrom messages specifying the pseudo-vat's VatID; the normal gift table mechanism would require that there be a live connection between the pseudo-vat-instance and the replica-vat.