feat: implement creation wallet with fireblocks #824

pixelplex · 2025-11-03T09:48:28Z

Signed-off-by: Alina Radyukevich <[email protected]>

mjuchli-da · 2025-11-03T11:03:58Z

api-specs/openrpc-user-api.json

-                        }
-                    },
-                    "required": ["wallet"]
+                    "$ref": "#/components/schemas/Null"


I think we can and should return a Wallet. For signing providers internal and participant, we should leave the code unchanged, and for fireblocks we can still create and return a wallet but just set the status accordingly.

Or is it because the partyId is not known yet due to a missing public key, from which the namespace (right side of the partyId) is derived?

No, I think I’ll be able to bring that logic back

mjuchli-da · 2025-11-03T11:07:05Z

api-specs/openrpc-user-api.json

            "description": "Allocates a new wallet and party with the given hint."
        },
+        {
+            "name": "allocateWallet",


At first glimpse, I don't think this extra api method is necessary. externalTxId and topologyTransactions could just be properties of an additional object CreateWalletParams.signingProviderContext.

I think it's more convenient to separate the logic the way I did now, because they perform slightly different actions. But if you feel it's better to combine them into one, I can refactor it.

mjuchli-da · 2025-11-03T11:07:18Z

api-specs/openrpc-user-api.json

+                                "type": "string",
+                                "description": "The signing provider ID the wallet corresponds to."
+                            },
+                            "txId": {


externalTxId

mjuchli-da · 2025-11-03T11:07:33Z

api-specs/openrpc-user-api.json

+                                "type": "string",
+                                "description": "The transaction ID"
+                            },
+                            "transactions": {


topologyTransactions

mjuchli-da · 2025-11-03T11:12:29Z

core/wallet-store-sql/src/migrations/002-init.ts

+        SELECT party_id, "primary", hint, public_key, "namespace", chain_id, signing_provider_id FROM wallets
+    `.execute(db)
+
+    await db.schema.dropTable('wallets').execute()


This removes an existing wallet table. The migrations are meant to contain incremental changes such as adding a field to an existing table. Given that your fields are nullable, I think this should actually work here.

Besides, did you think of potentially creating a separate table for the fireblocks related additional information?

I'm creating a new table called wallets_temp, where party_id will no longer be the primary key and an auto-incrementing ID will be used instead. Then I copy all the data from the wallets table into wallets_temp. Once all the data has been copied, we can delete the old wallets table and rename wallets_temp to wallets. This way, party_id will no longer be the primary key, and we'll be able to create wallets with an empty party_id.

See my suggestion below to keep the party_id as the private key

mjuchli-da · 2025-11-03T11:12:38Z

core/wallet-store-sql/src/migrations/002-init.ts

+        SELECT party_id, "primary", hint, public_key, "namespace", chain_id, signing_provider_id FROM wallets ON conflict do nothing
+    `.execute(db)
+
+    await db.schema.dropTable('wallets').ifExists().execute()


Same as above

The migration down happens in reverse order. We transition from the new table with id as the primary key back to the old table with party_id as the primary key.

mjuchli-da · 2025-11-03T11:18:07Z

core/wallet-dapp-remote-rpc-client/src/index.ts

 *
 */
 export interface Wallet {
+    id: WalletId


This feels unnecessary since partyId is unique...

We need to add an ID and start using it as the primary key because we're going to store the wallet in the database before we know its party_id. As a result, there may be multiple records with an empty party_id, so it will no longer be unique

We are able to form the partyId (hint::namespace, where namespace=hash(publicKey)) by using the public key you select in the controller here: (https://github.com/pixelplex/splice-wallet-kernel/blob/pixelplex/fireblocks-wallet-creation/wallet-gateway/remote/src/user-api/controller.ts#L224)
To create the fingerprint, you can use the createFingerprintFromKey method found here:

splice-wallet-kernel/core/ledger-client/src/topology-write-service.ts

Line 190 in b0aab8b

static createFingerprintFromKey(publicKey: string): string

As a result, we can predefine the partyId, before it's transactions are signed by fireblocks and the party is allocated on the participant node.

mjuchli-da · 2025-11-04T09:37:15Z

wallet-gateway/remote/src/user-api/controller.ts

+                })
+
+                if (!['pending', 'signed'].includes(status)) {
+                    await store.removeWallet(params.id)


We do we remove it here?

Because if the status of our transaction is neither pending nor signed, it means it has either failed or been cancelled. In that case, we’ll never be able to allocate the wallet, so there’s no need to store it in the database

Signed-off-by: Alina Radyukevich <[email protected]>

mjuchli-da · 2025-11-06T19:38:39Z

core/wallet-store/src/Store.ts

    addWallet(wallet: Wallet): Promise<void>
-    // removeWallet(partyId: Wallet): Promise<void>
+    updateWallet(params: UpdateWallet): Promise<void>
+    removeWallet(partyId: string): Promise<void>


Suggested change

removeWallet(partyId: string): Promise<void>

removeWallet(partyId: PartyId): Promise<void>

mjuchli-da · 2025-11-06T19:41:47Z

core/wallet-store/src/Store.ts

    setPrimaryWallet(partyId: PartyId): Promise<void>
    addWallet(wallet: Wallet): Promise<void>
-    // removeWallet(partyId: Wallet): Promise<void>
+    updateWallet(params: UpdateWallet): Promise<void>


Why don't we just allow updating all fields of a wallet (identified by partyId):

updateWallet(wallet: Wallet): Promise<void>

Maybe it could be better just rename this method from updateWallet to updateWalletStatus?

linushkar added 2 commits November 3, 2025 08:58

feat: implement wallet creating using fireblocks signingProvider

fdfb226

Signed-off-by: Alina Radyukevich <[email protected]>

change README

2b382dc

Signed-off-by: Alina Radyukevich <[email protected]>

pixelplex requested review from a team as code owners November 3, 2025 09:48

mjuchli-da requested changes Nov 3, 2025

View reviewed changes

mjuchli-da reviewed Nov 4, 2025

View reviewed changes

fix comments

0945557

Signed-off-by: Alina Radyukevich <[email protected]>

mjuchli-da reviewed Nov 6, 2025

View reviewed changes

	removeWallet(partyId: string): Promise<void>
	removeWallet(partyId: PartyId): Promise<void>

feat: implement creation wallet with fireblocks #824

Are you sure you want to change the base?

feat: implement creation wallet with fireblocks #824

Conversation

pixelplex commented Nov 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjuchli-da Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mjuchli-da Nov 4, 2025 •

edited

Loading