Protocol for Sponsored Transactions

📜 Development Proposals Starknet Technical Development
1

Hello everyone,

I am Pilou from Sekai. We are currently building a collectible card game on StarkNet where users could purchase boosters of cards and open them.

Our main problematic is that we would like to cover the gas fees for the users when they open a booster. As they own the asset (aka the booster) on-chain, they are the ones who need to call the booster contract from their account. The signature on the opening transaction must be computed using the user’s signer.

To tackle this, we designed a protocol in which users sign their transactions including the payer (address of the account that will pay for the transaction) in the signed calldata.
The user’s transaction also takes the nonce from the payer account as it will be the one bumped by the execution.
The sponsored transactions are then sent to the classic execute endpoint of the payer account contract (classic OZ Account implementation here). The payer forwards it to the executePaid endpoint of the user account contract (PayableAccount implementation).
This endpoint recomputes the transaction hash of the original user transaction and checks it against the provided user’s signature.

This flow is illustrated in the attached diagram.

Here is an example of such a sponsored transaction : Starkscan - Starknet Block Explorer

I put together a repository to open-source the protocol and get feedback from the StarkNet community : GitHub - sekai-studio/paymaster: Model Account Contract to leverage paymaster protocol

For now, it’s written in “already old” Cairo and tested in Python as I needed to experiment quickly (and not learn a new language). It will be migrated to Cairo 1.0 once the language is stable and the protocol reviewed.

The Cairo part of the repo consists of the PayableAccount implementation.
The Python part offers a library to generate/sign/invoke sponsored transactions in a easy way.

I will also add some more test cases in the next weeks but wanted to have some feedback about this protocol first.

Happy to discuss with you all :smile:

Thanks,

Pilou

N.B. : do not pay attention about the data used in the example transaction, we are just big Naruto fans, there’s nothing official !

payamaster_flow
payamaster_flow4935×1725 113 KB

30 Likes
2

Love the idea !

Have you thought about a way to add some security for the payer, such as whitelisting or rate limiting, to protect the payer account from potential abuse like someone spamming transactions on booster opening ?

11 Likes
3

for coming out with this Idea, I say well done.I hope the codes will be migrated to cairo 1.0 soon(if i am right). Can’t wait to see the product come alive, I would love to be one of your testers of Sekai app in future. More grease to your elbow and your team as well. iLeadmangh

9 Likes
4

It’s great to see how Sekai is leveraging the power of StarkNet to build a collectible card game and cover gas fees for users. The protocol you designed seems well thought out and your decision to open-source it and seek feedback from the StarkNet community is commendable. Also, as a fellow Naruto fan, I appreciate the use of the character names in the example transaction! :sweat_smile:

1 Like
5

If i recall the guys at cartridge.gg sponsored my transition minting a non fungible football player, may be a good idea to speak to them.

6

Ah yeah, that’s a good idea. Thanks for bringing it up !

7

Haha thanks, appreciate it !

8

Thanks for the kind words !

9

Thanks !

As the payer’s nonce is signed by the user as part of the transaction calldata, we already have a rate limiter by default. It’s impossible to spam a single transaction as it is linked to a single nonce. Also, only the payer address linked to the transaction can execute this transaction so you have the whitelisting here.

Now, if you were wondering about something more permissive where a whitelist of payers could execute any transaction that was signed before, we would indeed need another kind of rate limiter (X transactions/payer or X transactions per Y blocks).
In such a system, the payer’s nonce wouldn’t be included in the transaction’s calldata and we would have to check if the whitelisted payer can execute the transaction without hitting the rate limiting.