Feature Request: Allow signing by external services.

[ymatienzo]

What problem does your feature solve?

Transaction signing

What would you like to see?

Is it possible to think of a way to sign transactions via an external service? I think that this will increase the usability of this tool. Different companies have different requirements regarding the management of the keys.

However, the implementation should be done in a way that lets the handling of the process of signing to the external service and the process of submitting to the network to the SDP.

The tool should send the transaction to be signed, and just get the signature back from the signer (Is there a SEP for this?). We should not do it like the anchor platform that limits the external signature just to Fireblocks!

Since the SDP is already using Kafka, adding transactions to be signed to a queue, wait for the signature, get them signed and then put it to a queue to be submitted should not be a problem.

What alternatives are there?

None that I know of.

[marwen-abid]

Feature Consideration

We're actively considering implementing a feature like this to support external transaction signing services. This would indeed increase the usability and flexibility of the SDP for organizations with different key management requirements.

Proposed Implementation: Transaction Signing Agent (TSA)

Our planned approach involves introducing a new application called a Transaction Signing Agent (TSA) with the following characteristics:

TSA Overview

• Self-hosted by the organization - Each organization maintains control over their signing infrastructure
• Multi-signer support out-of-the-box - Built-in support for multiple signing providers
• Open source and extensible - Organizations can extend and customize the TSA for their specific needs
• API-based communication - Clean separation between SDP and signing logic. This will probably involve one or two endpoints and support batch signing.

Architecture

• SDP ↔ TSA API Integration - The SDP communicates with the TSA through a well-defined API
• Flexible deployment models:
  • Multi-tenant setups - Each tenant organization can run their own TSA instance
  • Self-hosted deployments - Single organization controls both SDP and TSA
• Process separation - SDP handles transaction preparation and network submission, TSA handles signing

---

This feature is under consideration and subject to roadmap prioritization. We welcome community feedback and contributions to help shape the final implementation.

[ymatienzo]

This is amazing @marwen-abid: The architecture looks in the right track. I will think a bit further and see if there is anything else that might need to be added. Thanks!