A fleet relay can read what it forwards, unless you seal the payload.
By default, multi-hop forwarding through fleet members re-encrypts per hop, and sealing the payload end to end is an opt-in. Why. A relay that cannot read the header cannot make a forwarding decision, and a relay that must open and re-seal every payload for routing would do so anyway; the per-hop model is the honest statement of what a trusted member on the path can see. On request. End-to-end sealing is already shipped as an option; the hosted traversal relays are the other model, and see only envelopes. Meanwhile. Place relays on members you trust with the payload, or turn end-to-end sealing on.
The trade-off. Hop-by-hop keeps per-leg rekeying every 120 seconds and per-neighbour replay protection, adds no bytes, and carries every traffic type, including broadcast, multicast and the FEC class; its cost is that a trusted relay reads the payload and could rewrite the origin field unnoticed. End-to-end sealing ([crypto] e2e) gives a relay nothing to read, uses a non-interactive key with no handshake, no per-pair state and no first-packet latency, binds the sender and the class under the seal so a tampering relay is caught at the destination, and passes through relays that have not enabled it. It costs 67 bytes per packet, so a full-MTU packet becomes two fragments per hop; it covers unicast only; it does not combine with the FEC class; it has no replay window and no forward secrecy of its own, the hop layer providing both per leg; a relay can no longer classify a sealed payload; and both ends must turn it on. Relay CPU is the same either way, since the hop layer is still opened and re-sealed at every hop; the endpoints add one seal and one open.