Uploaded image for project: 'Indy Node'
  1. Indy Node
  2. INDY-1999

POA: Transaction authors don't need to be endorsers



    • Type: Story
    • Status: Complete
    • Priority: Medium
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 1.9.1
    • Component/s: None
    • Labels:
    • Sprint:
      Ev-Node 19.15
    • Documentation Impact:


      As a transaction author, I need my transactions to be written to the ledger preserving me as the author without my needing to accept the responsibilities of an endorser so that I can focus on my business. Instead, I will have a business relationship with an endorser who will endorse my transactions.


      • It is easy to tell from the ledger who is the endorser and who is the transaction author for each transaction.
      • A transaction author can use a different transaction endorser for future transactions, including updates to attribs and key rotations.
      • The transaction must use the author key to sign the transaction author agreement regardless of whether an endorser signature is also needed.
      • If the endorser field is included in a transaction, then the ledger will reject the transaction if it is not signed by the endorser.

      Acceptance Criteria

      • Analyze the work required.
      • Raise issues for completing the work.


      • The transaction author field is intended to be used for all future permissions.
      • The endorser field only needs to be recorded in order to:
        • Allow auditability, that the transaction was written with correct permissions
        • Allow the network administrator to bill the endorser for the write
      • Sub-endorsers or chains of endorsers would be desirable for a global network, but are not required at this time. We recognize that in the future adding multiple levels of endorsers or delegated endorsers could be a breaking change.
        • Endorsers could be a list, but it would still require the transaction author to know all endorsers at the time the transaction is created. That list could be built off-ledger by sharing a draft transaction.
      • Suggested user flow:
        • Transaction author identifies the need for creating a transaction
        • Transaction author identifies which endorser they want to use
        • Transaction author includes the DID of the endorser in the transaction, and signs the transaction.
        • Transaction author passes the signed transaction to the endorser
        • Endorser adds their signature
        • Endorser submits the multi-signed transaction to the ledger
        • If the endorser will not accept the transaction, and the transaction author wants to try a different endorser, the transaction author must recreate the transaction in order to include the new endorser DID.
      • This process is separate from a potential process by which payment could be attached to a third party transaction so as to allow it to be written to the ledger. That potential feature of the Sovrin Network is being tracked in ST-608. In other words, transaction endorsers and authors don't need to be tracked separately for Sovrin XFER transactions.


          Issue Links



              ashcherbakov Alexander Shcherbakov
              esplinr Richard Esplin
              Alexander Shcherbakov, Richard Esplin
              0 Vote for this issue
              2 Start watching this issue