I don't what this xx_execprocs did, but maybe they had EXECUTE AS = 'xx_execprocs' in some parent procedure. As they grant EXECUTE permission, I suspect that they had a broken ownership chain somewhere as well. In any case, that was then, this is now.

And now, you should create a certificate, create a user from that certificate, grant that user ALTER on the table to be truncated, and sign the procedure with the certificate. The simplest is to put it all in the file that holds the stored procedure (I'm assuming that you have all under version control.) There is no need to have the password in the file - use a guid() as a throwaway password. There is a script in my article to demonstrates how to this for server-level permissions.

If you are OK with database chaining, you can stay with that. But my article also includes an example how to cross-database access with help of certificates.