PTB, adminCap and object owners

SDK
1

Hi there.

I have been cracking my head over last few days to try and do few thing and I really can’t find my way out so I need to ask a few questions to make it maybe more clear for me if there are limitations that are preventing me from building things the way I need.

Is this possible in PTB?

  1. User sends objects to admin
  2. Admin uses Move with adminCap to mutate the objects
  3. Admin sends back objects to user

That would kinda require two signatures and Im not sure if the move contract would be able to act like objects are currently owned by admin.

All my tries resulted in my ExecutTransactionBlock to ask for just one signature and Im unable to send two signatures even tho the prop has an option of array.

Now maybe something like this is not possible and I need to create additional object in my contract that will enable users to mutate their nfts but can that also be done in PTB? I create and send object to the user, users mutates the nft and burns the object. ? That would require both sides to sign.

Thank you!

2

Short answer: not in the exact shape you described.

A normal address-owned object can only be used in a transaction signed by its owner. So if the NFT/object is owned by the user, an admin-signed PTB cannot take &mut access to it. Likewise, if the AdminCap is owned by the admin, a user-signed PTB cannot use that AdminCap.

The signatures: [] field is a bit easy to misread here. It does not make a PTB a general “multi-owner transaction” where objects owned by arbitrary addresses can all be consumed together. The common cases are:

  • a multisig address, where multiple keys authorize one Sui address;
  • a sponsored transaction, where the sender and gas owner both sign, but that is about gas ownership, not arbitrary access to each signer’s owned objects.

So this flow usually needs to be modeled as either:

  1. Two transactions / escrow flow

    • User deposits or transfers the object into an escrow/shared/object-owned object.
    • Admin later uses AdminCap to process it and return/release the object.

  2. Permit / capability flow

    • Admin signs or mints a one-time Permit object and transfers it to the user.
    • User submits a PTB that mutates their own NFT and consumes/burns the permit in the same Move call.
    • This is often the cleanest if the NFT should stay user-owned and the admin just needs to authorize a specific action.

For example, instead of requiring AdminCap during the user’s mutation, make the admin-only function issue a typed permit:

mint_permit(&AdminCap, nft_id, recipient)

Then expose a user-callable function like:

mutate_with_permit(nft: &mut MyNft, permit: Permit, ctx: &mut TxContext)

Inside mutate_with_permit, verify the permit matches the NFT/action/expiry/nonce, mutate the NFT, and destroy the permit so it cannot be reused.

If you truly need both parties to approve the same operation atomically, then the objects need to be owned by a common authority model, such as a multisig-owned address/object, or you need to verify the admin’s authorization inside Move using an explicit permit/signature. Passing two transaction signatures alone will not grant Move access to both accounts’ owned objects.