For issue a) you can create a v2 version and, if you really really want to keep the crypto_box calls in your source code, you #define crypto_box crypto_box_v2

For issue a) you can create a v2 version and, if you really really want to keep the crypto_box calls in your source code, you #define crypto_box crypto_box_v2 -- your code won't change, but when you compile, the symbols will change. After that, if you try to link against this library with code that isn't updated you'll fail at build time. That being said, I think replacing all instances of crypto_box to crypto_box_v2 is much better than #defining The #define trick only makes problem b) bigger -- I think that if/when a new cryptobox is needed the upgrade strategy will be the following: 1) the new crypto_box will be named crypto_box_v2 2) create a new api endpoint using crypto_box_v2 that isn't being used. If you semver your api endpoints, that means doing a major version bump since it won't be backwards compatible with the older crypto. Does this suck? yes. 3) migrate traffic to the new api endpoint 4) EOL the old api endpoint When you think about it, it's the only way to do it and cipher negotiation is only masking steps 1-4 (i.e doing it for you, but in an opaque way)