With all due respect, you read completely wrong. * The very first use case for which Cap'n Proto was designed was to be the protocol that Sandstorm.io used to

With all due respect, you read completely wrong. * The very first use case for which Cap'n Proto was designed was to be the protocol that Sandstorm.io used to talk between sandbox and supervisor -- an explicitly adversarial security scenario. * The documentation explicitly calls out how implementations should manage resource exhaustion problems like deep recursion depth (stack overflow risk), were many serialization formats leave these things as the app's problem. * The implementation has been fuzz-tested multiple ways, including as part of Google's oss-fuzz. * When there are security bugs, I issue advisories like this: https://github.com/capnproto/capnproto/tree/v2/security-advisories https://github.com/capnproto/capnproto/tree/v2/security-advi... * The primary aim of the entire project is to be a Capability-Based Security RPC protocol. That's what "Cap" in the name comes from. The zero-copy serialization is actually a bonus feature. (I'm the author of Cap'n Proto.)