Okay, so you're saying that it's not a complete WireGuard implementation and not functional. Every WireGuard endpoint must have an IP address (or subnet) on the encrypted subnet. If an endpoint doesn't have one, WireGuard cannot route traffic to that endpoint.

You said the handshake is establishing a tunnel, and that it is delivering raw traffic, but how is that possible in a L3 environment that uses IP addresses to determine route(s) to an endpoint? When you refer to "encapsulated traffic", you probably mean traffic from the unregistered endpoint to a known WireGuard server, This would give the known WireGuard server the public IP of the unregistered endpoint, but unless the WireGuard server has an IP address for the unregistered endpoint's encrypted L3 subnet, no traffic will ever flow in the other direction.

A few years ago, I had an idea for a secure way for two WireGuard endpoints to find each others' public IP address, which I have not yet implemented, but even in that environment both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.

Some background on my WireGuard experience:

I've set up a lot of WireGuard systems and have even done some WireGuard demonstrations for government research purposes (over five years ago, before I retired).

Right now I'm maintaining (for myself, my family, some former consulting clients, and two of our security systems) a dual-stack multi-point WireGuard network with three cloud servers, and about 30 endpoints scattered across four physical locations and five mobile devices. I even set up some kludgy scripts so that two of the locations using dynamic IP can communicate directly point-to-point with each other, and fall back to one of the cloud-based WireGuard routers to re-sync if/when one of their public IP addresses changes. Direct point-to-point communication cuts latency in half and reduces my cloud data fees.