0

I get a signer privilege escalated error and I suspect that it is because I am incorrectly passing the signers to the executing thread instruction.

Here is roughly how MyContext looks like (including pda initialization):

pub struct MyContext<'info> {
    #[account(
        init,
        seeds=[...],
        bump=,
        payer = creator,
    )]
    pub acc: Account<'info, MyAccount>,

    #[account(mut)]
    pub creator: Signer<'info>,

    #[account(signer, address = thread.pubkey())]
    pub thread: Account<'info, Thread>,
}

This is how I invoke the associated MyContext instruction:

    const ix = await myProgram.methods
        .myContextIx({...})
        .accounts({
            acc: acc,
            creator: signer.publicKey,
            thread: threadPubkey,
        })
        .instruction()

    const thread_transaction = await threadProgram.methods
        .threadCreate(
            threadName,
            {
                programId: myProgram.programId,
                accounts: ix.keys,
                data: ix.data,
            },
            trigger
        )
        .accounts({
            authority: signer.publicKey,
            payer: signer.publicKey,
            thread: threadPubkey,
            systemProgram: anchor.web3.SystemProgram.programId,
        })
        .rpc();

So I am wondering how do I make a thread execute a designated instruction that requires another signer. In this case, both the thread and the creator account?

I can see from the thread_exec.rs source code, that the signer for the thread CPI instruction call is always going to be the thread account, so is it even possible to consider another signer?

1 Answer 1

1

Clockwork founder wrote:

Ah! If you need just any arbitrary payer, use the PAYER_PUBKEY here. This is a special pubkey that tells the workers to insert their own pubkey in its place, allowing you to spend from their wallet to pay for things like account initialization. Outside of the thread account, this is the only other way to get a signer on an instruction invoked by a Clockwork thread. It simply isn't possible to have an end-user be the signer on an automated instruction. The workers cannot sign for private keys that they do not have access to. The whole idea behind Clockwork's security model is that your effectively delegating signing to a PDA. Wallet signatures are really hard to automate (because you don't want to expose the private key), but PDAs are much easier because you can gate their signatures by logic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.