Skip to content

Conversation

fondation451
Copy link

Motivation and Resolution

Before, there was only a default signer with direct access to the private key. I have been using wallet provider such as Dfns which provides signing functions as a service. I derived from the implementation of the default signer, a signer that rely on an external service. I think that it may be useful to have it in the library.

Usage related changes

  • Introduction of a new signer to use external signing service such as Dfns

Development related changes

  • It is based on the default signer. All the method that needs the private key are overwritten to use the external service

Checklist:

  • Performed a self-review of the code
  • Rebased to the last commit of the target branch (or merged it into my branch)
  • Linked the issues which this PR resolves
  • Documented the changes in code (API docs will be generated automatically)
  • Updated the tests
  • All tests are passing

@tabaktoni
Copy link
Member

I don't see a gain in doing a simple wrapper, as any dev can extend Signer on their own for whatever it's needed.
But if we are going to merge this, it would need some examples in the documentation on how to use it.
Can you add these examples @fondation451 for the Dfns you mentioned?

@tabaktoni
Copy link
Member

bump

@adrienlacombe
Copy link

@tabaktoni this is dfns @fondation451 is talking about https://docs.dfns.co/d/api-docs/keys we know that some dapps on Starknet are using it as KMS

@tabaktoni
Copy link
Member

tabaktoni commented Jun 4, 2025

This is fine, but we need either tests or at least documentation examples of how the devs would use it.

@adrienlacombe
Copy link

@fondation451 could you please add tests and doc 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants