Sponsorships are critical in the Stellar blockchain ecosystem for optimising transaction procedures and promoting equitable interactions. Because transactions sometimes include fees for various activities such as forming trust lines or beginning payments, sponsorships provide a means to alleviate one party’s financial burden while maintaining seamless execution. Sponsorships improve the efficiency, accessibility, and fairness of transactions on the Stellar network by allowing one organisation to cover the costs associated with another’s actions, resulting in a more inclusive and streamlined blockchain experience.

Sponsorships: Empowering One-Sided Transfers

Consider the following scenario: Party A wishes to present a token to Party B. The Stellar network requires the recipient to have a trust line for the token, which is commonly accomplished by performing the Change Trust function. However, both the Change Trust and Payment processes are charged. Party B would normally have to pay for the trust line creation even though they are getting a gift, which may appear contradictory.

Stellar proposes the concept of sponsorships to address this. Party B’s trust line can be sponsored by Party A or a third party through sponsorship. This means that the cost of activating the trust line is borne by someone else.

 

Step-by-Step Sponsorship Instructions

Let’s go over the stages required in establishing sponsorships for one-sided transfers:

Party A (or a third party) initiates the sponsorship process by adding the Begin Sponsoring Future Reserves procedure to the transaction. This is the start of the sponsorship relationship.

Activation of the Trust Line(or any other operation): Party B discloses its public key, allowing Party A to build the trust line on its behalf. This allows Party A to activate the trust line without having to pay Party B.

End Sponsoring Future Reserves Operation: Party B adds the End Sponsoring Future Reserves operation to the same transaction. This completes the sponsorship arrangement, and Party B’s account is no longer inextricably linked to Party A’s funding.

Sponsorships for Multiple Operations

Each operation must be sandwiched between Begin and End Sponsoring Future Reserves activities in scenarios involving several operations. This keeps the sponsorship context consistent throughout the transaction.

Account Sponsorships for New Accounts

If Party B does not already have a funded account, a slightly modified procedure is used:

Party B creates a keypair and reveals its public key.

Party B’s account must be financed before it can be activated. This is accomplished using the Create Account process.

The Create Account activity, like the preceding one, is sandwiched between the Begin and End Sponsoring Future Reserves operations.

 

Signatures and Multi-Signatures Bring it All Together

The security of transactions on a public blockchain such as Stellar is critical. Developers frequently use multi-signature techniques to address security problems and assure transaction integrity. In this post, we will look at how to add single/multi-signatures to a prebuilt Stellar Transaction Envelope using the Go programming language and the txnbuild and xdr SDKs.

 

SDKs Used

txnbuild: This SDK provides a comprehensive implementation of transaction operations for the Stellar distributed ledger. You can find more about it here.

xdr: The xdr package from github.com/stellar/go/xdr offers encoding and decoding capabilities for Stellar XDR types.

 

Signing a Prebuilt XDR: Step-by-Step Guide

Step 1: Parse XDR and Unpack Transaction

Assuming you have the XDR as a string, the first step is to parse the XDR and unpack it into a transaction object.

import (
 "github.com/stellar/go/txnbuild"
 "github.com/stellar/go/xdr"
)




func main() {
 // Assuming transactionXDR is your pre built XDR string
 transaction, err := txnbuild.TransactionFromXDR(transactionXDR)
 if err != nil {
 // Handle error
 }
 txe, _ := transaction.Transaction()
}

 

Step 2: Get Network-Specific Hash

Generate a network-specific hash for the transaction using either the test net or public net passphrase.

networkPassphrase := network.PublicNetworkPassphrase // or network.TestNetworkPassphrase
hashXDR, err := txe.Hash(networkPassphrase)
if err != nil {
// Handle error
}

Step 3: Create Decorated Signature

Create a decorated signature using the signer’s keypair. This signature includes the hint and actual signature.

signer := SignerKeypair // Replace with the actual signer's keypair
signature, err := signer.SignDecorated(hashXDR[:])
if err != nil {
// Handle error
}

hint := signer.Hint()
decoratedSignature := xdr.DecoratedSignature{
Signature: signature.Signature,
Hint:      hint,
}

Step 4: Add Decorated Signature to Transaction

Add the decorated signature to the transaction envelope.

txe, err = txe.AddSignatureDecorated(decoratedSignature)
if err != nil {
// Handle error
}

Step 5: Convert Transaction Back to XDR

Convert the transaction envelope with the added signature back to XDR format.

xdrsign := txe.TxEnvelope

Step 6: Convert XDR to Base64

Convert the XDR to base64 encoding for submission.

bs64xdr, err := xdrsign.Base64()
if err != nil {
// Handle error
}

You have now successfully attached a signature to your Stellar Transaction Envelope. The bs64xdr is now ready for Stellar network submission.

When dealing with public blockchains, security is of the utmost importance. Using multiple signatures improves transaction confidence and integrity. By following the techniques detailed in this article, you can reliably append signatures to prebuilt XDRs, guaranteeing that your transactions on the Stellar blockchain are secure and tamper-resistant. To ensure the maximum level of security, always handle mistakes responsibly and keep your secret keys safe.

 

Use Cases and Importance of Multi-Signatures in Stellar Transactions

Let’s look at some frequent use cases where multi-signatures are required and how they affect the process:

Use Case 1: Scenario of Business Account Control: Financial decisions in business frequently necessitate the consent of various stakeholders. Multi-signature systems can be used to manage the use of corporate funds and ensure that no single individual can initiate transactions unilaterally.

Importance: Before a transaction can be conducted, a predetermined number of authorised signers must collectively approve it. This prevents a single individual from squandering business resources and adds an extra layer of accountability. Even if one signer’s key is compromised, an attacker cannot initiate transactions without the consent of the other authorised signers.

Use Case 2: Escrow Services Scenario: Escrow services entail a third party holding funds until specific conditions are met. Multi-signatures can be used to form an escrow arrangement in which the release of funds requires both the buyer and seller’s permission.

Importance: Before funds are released in an escrow scenario, all parties require confidence that the terms of the transaction will be met. The use of several signatures ensures that neither side may release funds unilaterally. This avoids fraud and provides a fair and safe method of conducting transactions, particularly in online marketplaces where trust between parties is restricted.

Use Case 3: Joint Accounts Scenario: For a variety of reasons, individuals or entities may share a shared account. To control the transfer of funds from this joint account, multi-signatures can be employed.

Importance: Joint account holders may wish to ensure that no individual can remove huge quantities of money on their own. They can specify regulations for fund transfers using multi-signatures, requiring the agreement of a majority or all account holders. This feature safeguards against conflicts and unauthorised transactions.

Use Case 4 : Security Token Offerings (STOs): Security Token Offerings include the distribution of digital tokens representing ownership in an asset. To govern the issuance and distribution of these tokens, multi-signatures can be used.

Importance: STOs require regulatory compliance as well as the accurate distribution of tokens to authorised investors. Multi-signatures can impose a controlled token release mechanism in which many stakeholders, such as legal representatives and administrators, authorise token transfers collectively. This assures regulatory compliance and decreases the danger of fraud.

Use Case 5: Governance Decisions: Governance choices in decentralised organisations or blockchain projects may be decided collaboratively by key individuals. Multi-signature transactions can be used to start and validate governance transactions.

Importance: Governance decisions frequently necessitate agreement among major parties. Multi-signatures enable these stakeholders to ratify proposals, budget allocations, or protocol upgrades as a group. This process ensures that major decisions are taken cooperatively and that no single entity wields undue influence.

Multi-signatures provide a solid security framework that prohibits unauthorised or malicious transactions, enforces accountability, and improves the integrity of blockchain-based transactions in all of these use cases. Multi-signatures mesh nicely with the concepts of trust and transparency that underpin blockchain technology by requiring many parties to sign off on a transaction.

 

Conclusion

In the area of Stellar blockchain, the convergence of sponsorship operations and multi-signatures creates a natural synergy that emphasises the platform’s dedication to security, efficiency, and inclusivity. Sponsorships ease the contradiction of asking one party to cover the expense of transactions that benefit another, promoting smoother one-sided transfers and minimizing wasteful expenditures. Simultaneously, multi-signatures strengthen transactions by requiring collaborative consent, increasing confidence and accountability. By combining these processes, Stellar cements its position as a strong and user-centric blockchain solution, enabling a dynamic ecosystem in which transactions are secure, seamless, and equitable for all participants.