Leveraging Particle Auth as an authentication mechanism within Openfort’s tech stack.
@openfort/openfort-node
though they also provide Unity and UE5 SDKs.). We’ll be focusing on the process of creating a new player and facilitating a signless and gasless transaction.
Achieving this requires three main steps (after logging in with Particle Auth):
name
(ideally the email of your player, retrieved through userInfo
upon social login) and description
(often the Signer address— the EOA generated by Particle Auth). This request will then return an associated player ID (and other information, such as the player’s Smart Account address) and register the previously created player on the Openfort dashboard, indicating that this user now has both an EOA secured by MPC-TSS (with Particle Auth) and Smart Account usable with Openfort.
Interaction
, the gas sponsorship policy, etc.). This transaction will then be signed by the saved session key and settled on-chain, minting the NFT without the user needing to confirm any pop-ups or pay gas fees.
{your openfort object}.players.create
, with {your openfort object}
being an instance of Openfort
(imported from @openfort/openfort-node
), constructed using your Openfort API key (sk_*
). Your Openfort API key can be retrieved from the Openfort dashboard.
This object can then be used to create a player through the aforementioned method, .players.create
, in which you can pass a name
(which can be set to the email or ID associated with an account generated by Particle Auth, retrieved through getUserInfo
, either through API or SDK) and description
, which can be the signer’s address.
particle.auth.login
or connect
, see Web (Desktop) Quickstart). In this example, we’ve set up the login process through an API call that returns the player ID to be used in session key creation and transaction execution. This endpoint is executed automatically after logging in with Particle Auth, setting a state for the player ID.
If successful, a new entry should be made to the “Players” tab on the Openfort dashboard, logging the data previously used to initialize the account.
CreatePlayerSessionRequest
(a type imported from @openfort/openfort-node
). In this example, our CreatePlayerSessionRequest
object will contain the following information:
playerId
, the player ID previously generated and retrieved through the account creation process.address
, the public key in which the session key will exist.
{your openfort object}.sessionKey.address
after calling {your openfort object}.createSessionKey
and {your openfort object}.saveSessionKey
.chainId
, any supported chain that you’re hosting your application on (Polygon Mumbai in this example).validUntil
and validAfter
, the temporal conditions of the session key, determining the duration of time until it’s active (if not immediately) and then expires (if ever).policy
, a gas sponsorship policy ID defined within the Openfort dashboard.externalOwnerAddress
, the public key of the EOA created by Particle Auth.{your openfort object}.players.createSession({your CreatePlayerSessionRequest object})
, as shown below.
playerSession
, in this case, is an object containing the UserOperation
and associated hash, which we’ll need to sign with our EOA (Particle Auth) through the second half of our logic for session key initialization. After retrieving this object through the corresponding API endpoint, we’ll need to sign it with {your openfort object}.sendSignatureSessionRequest
, passing in data.id
from the playerSession
object alongside a call to {your provider object}.signMessage(json.data.nextAction.payload.userOpHash)
, with {your provider object}
referring to a constructed ethers/web3.js/etc. object with the signMessage
method available, sending a signature request to Particle, thus facilitating the initialization of the session key. See the following code snippet for an example of this.
0x38090d1636069c0ff1af6bc1737fb996b7f63ac0
), we’re ready to construct an Interaction
object to be used in the generation of a UserOperation, which will then be signed by our session key. Similar to CreatePlayerSessionRequest
, we need to import a specific object type, Interaction
, from @openfort/openfort-node
. Within an instance of Interaction
, you’ll need the following information:
contract
, the API ID of the contract recently added to the Openfort dashboard.functionName
, the name of the function you plan on calling (the list of available functions is included on the contract’s page within the dashboard).functionArgs
, the arguments for the function (which can also be found on the dashboard).Interaction
object should look similar to the snippet shown below.
{your openfort object}.transactionIntents.create
, facilitating the generation of a UserOperation to be signed and executed on the player’s behalf through the session key. This call will look nearly identical to the previously covered CreatePlayerSessionRequest
, but will rather be of type CreateTransactionIntentRequest
and contain the following parameters:
playerId
, the player ID previously generated and retrieved through the account creation process.chainId
, any supported chain that you’re hosting your application on (Polygon Mumbai in this example).optimistic
, whether or not the transactionIntent
is optimistic, meaning it resolves before settling on-chain.interactions
, the Interaction
object that was just constructed.policy
, a gas sponsorship policy ID defined within the Openfort dashboard.externalOwnerAddress
, the public key of the EOA created by Particle Auth.data
, as we’ll be using it during execution in a moment. In total, between the Interaction
and CreateTransactionIntentRequest
object, your code should look like the following:
{your openfort object}.loadSessionKey
. Upon loading the session key, rather than using a provider object to sign the UserOperation hash (as we did with the session key initialization), we can use Openfort directly with {your openfort object}.signMessage(data.nextAction.payload.userOpHash)
. This will automatically use the session key to sign the UserOperation hash and thus execute the transaction on behalf of the user, never requiring a manual signature.
This signed UserOperation will then need to be sent through {your openfort object}.sendSignatureTransactionIntentRequest
, as highlighted below:
App
component that players will interface with. An example of what this may look like has been included below.