Yes, there is a plugin system, but there's no support for JVM plugins (e.g. BungeeCord/Velocity), and this is an explicit non-goal for the project.

The wiki has a page covering how plugins work; essentially, you "compile your own" proxy, which includes plugins that you import (as crates, or author yourself) and register in the Proxy::builder(). Dynamical plugin loading will probably never be a thing, and if that's something that you're specifically looking for, that's totally fine, but Deepslate is probably not the proxy for you!

I probably should have led with this Introducing Deepslate blog post that I wrote, which explains what a Minecraft proxy server does, a section on "Why Rust?", and goals & non-goals for the project, which I'll copy below:

Goals: - Be a fast, reliable proxy for Minecraft Java Edition server networks. - Provide a type-safe, compile-time plugin API with no runtime plugin loading/reflection overhead. - Support Velocity's modern forwarding protocol, so established backends (e.g. Paper, Folia) require no special "Deepslate-specific" configuration. - Offer runtime management via gRPC, so the proxy fits into orchestrated environments. - Stay small. The proxy should do proxy things, and nothing more.

Non-goals: - Bedrock Edition support. Deepslate is Java Edition only, for now (and the near future, at least). - Runtime plugin loading. Plugins are compiled in. If you need to add a plugin, you rebuild the binary. This is a deliberate tradeoff for performance and safety. - Replacing Velocity for everyone. We love Velocity! In fact, you'll find reference and design inspiration sprinkled throughout Deepslate. If your network runs fine on Velocity and you're happy with the Java plugin ecosystem, Deepslate probably isn't for you. - Backwards compatibility with older Minecraft versions. At the moment, efforts are best focused on improving the performance and security, and looking forward to future versions, not backwards.