PDA signed CPI access control

Question

Imagine this usecase. We have a central treasury/vault, which holds all of the funds in the protocol. There are multiple separate games, which execute game logic, but do not hold the funds. Once game logic requires to deposit funds, they sent it to treasury/vault, and once logic requires to withdraw funds, they instruct treasury/vault to make a withdrawal.

The key here, is that the funds are mutual between different games and are pooled together. They also need to be securely accessed by the Treasury and different Games in the protocol, but no one else.

the only way I can think of implementing this is to have:

1. Treasury program which owns the general PDA which stores the funds, as well as allows for admin pubkey to interact with the PDA
2. Multiple separate game programs, which make CPI signed with game PDA into Treasury program in order to withdraw the funds.

The questions are:

1. is there a better practices/architecture to implement this?

Maybe it is possible to share the same account between different programs, with account being mutable in each of them.

2. is it possible to validate, that the CPI was made from specific game program, for example by retrieving the signing PDA, and comparing it against some hardcoded value?

I've read that it is not possible to retrieve the caller program ID in the callee.

3. If I would not make the treasury program code open source, would it be 100% impossible to make a CPI to it by some 3rd party (I am using Anchor)?

I've read, that it is possible to reverse engineer the code and make CPIs even if code is not public, thus access control is needed.

4. Puppet - Puppet master Anchor example seems outdated and JS test part does not work for me. Maybe there are another good examples of PDA signed CPI to another program (not System program, but native to project/user program)

Thanks in advance

Answer 1

Going through each question individually:

1. The design is perfectly reasonable. Depending on how each game is designed, you might be able to refactor some game logic into a combined account, but without knowing more, I can't say for sure if that's worth it.
2. You can't what program called you by default, but you can design a system to do it. For example, if program A calls to program B, program A can sign with a PDA and also provide the seeds used. Program B can check that the PDA signed and that it was derived using a certain program id. If everything checks out, then program B can be sure that program A signed somewhere. Note that it's technically possible for a program C to get in between, if program A calls into program C. I wouldn't necessarily worry about that case though as long as program A does some basic sanity checks.
3. You can publish just the IDL for the treasury program, then anyone can generate clients for your program, without exposing the implementation of the program. Or you can publish a "client" crate which only exposes instruction creators and state deserializers.
4. It's not an Anchor program, but https://github.com/solana-labs/solana-program-library/tree/master/examples/rust/transfer-tokens shows how to a simple signed CPI to the SPL token program