I am working on an application where it is required for the backend system to invoke transfer of funds at a later time(By later time, here means when the account owner is not present). Delegation looks like a candidate for the same, however the behavior observed for delegation doesn't seem to be intiutive to me. This is what I have gathered:

  1. Application 1[account1 owned by application 1] request approve instruction to consumer wallet
  2. Consumer wallet authorizes the instruction, account 1 has the delegation setup correctly.
  3. At a later instance(before account 1 is able to consume funds), some other application request delegation from the user and user authorizes that as well. In this scenarios, delegation setup as #2 will be revoked(without even customer being aware of it.)

I want to know

  1. if there is any documentation where this behavior is officially called out
  2. if anyone know the reasoning behind this (this behavior is different from ERC-20 approve instruction, where more than 1 sepender can be active on a token)
  3. In absence of multiple delegates, what are the alternatives to implement such solution.

Note: I am aware user can also revoke the delegation anytime and backend system transfer can fail. My concern with existing delegation is that customer may not be aware at all when the delegation is removed.

Thanks for your help.

1 Answer 1


The comment for the SPL-Token "Approve" instruction says:

"Approves a delegate. A delegate is given the authority over tokens on behalf of the source account's owner."

And Revoke says: "Revokes the delegate's authority."

One could interpret the use of the article "the" as implying that there is only one delegate per token account, thus implying that a second approve must necessarily replace the approved delegate, thus implicitly un-approving any prior delegates.

However, this is a pretty tenuous claim and not exactly very clear from these comments.

Looking at the implementation of the SPL-Token program, the definition of a token Account includes a single delegate, so it can only be the case that any new delegate overwrites the previous delegate. This matches the interpretation of the wording as described above.

The SPL-Token program is "frozen" and cannot (under normal conditions) change, so you can count on it always being the case that a new delegate will overwrite (and thus implicitly "revoke authority" of) any prior delegate.

I do not know why the SPL-Token program was designed to support only one delegate per token account.

In terms of alternatives, the delegate could be set to be a Program Derived Address, the Program which is the owner of which could implement its own multi-delegate functionality. The Program would take as instruction input a signed delegator which matches one of many delegators it stores in its PDA associated with the token account, and then issue a cross-program invocation into the Token program with its own PDA as the signed delegator for that invocation.

This type of composition through Programs using PDAs as authority accounts is a very common way of solving similar problems on Solana.

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.