This issue lists the changes to the Horizon API introduced by CAP-23 and CAP-33. These two CAPs comprise the public-facing changes in Stellar Protocol 14. The first Horizon version with the updated API is Horizon 1.9.0-RC, to be released 2020-09-21 (monorepo release page).

This protocol upgrade is purely additive. We expect a protocol 14 compliant SDK to be able to run successfully against a protocol 13 network.

We are aiming for the following timeline:

• 2020-09-21 Horizon 1.9.0-RC is released with support for protocol 14
• 2020-09-30 Testnet will vote to update to protocol 14
• 2020-10-28 Pubnet will vote to update to protocol 14

In what follows, "canonical form" means code:address or native (for the XLM asset).

New objects

• Claimable Balance with the following fields:
  • id - balance ID,
  • paging_token - paging token,
  • asset - asset available to be claimed (in canonical form),
  • amount - amount available to be claimed (string, like all amounts),
  • sponsor - sponsoring account ID (can be null),
  • last_modified_ledger - sequence number of the ledger when the balance was last modified,
  • claimants - list of objects:
    • destination - destination account ID,
    • predicate - predicate required to claim a balance (see below).

Modified objects

• Account object:
  • New sponsor field (account ID, can be null).
  • New num_sponsoring field - number of reserves sponsored by this account,
  • New num_sponsored field - number of reserves sponsored for this account.
• New sponsor field (account ID) in Account > Balance object (only for non-native assets, can be null).
• New sponsor field (account ID) in Account > Signers object (can be null).
• New sponsor field (account ID) in Account's Data object (can be null).
• New sponsor field (account ID) in Offer object (can be null).

New endpoints

• /claimable_balances - the list of Claimable Balance objects with the following parameters (only one param per request allowed):
  • asset - find all claimable balances with the given asset (in canonical form),
  • claimant - find all claimable balances with the given claimant account ID,
  • sponsor - find all claimable balances sponsored by a given sponsor account ID.
• /claimable_balances/{id} - a single Claimable Balance object.

Modified endpoints

• /accounts can now by filtered by sponsor (new GET param).
• /offers can now by filtered by sponsor (new GET param).

New operations

• create_claimable_balance with the following fields:
  • asset - asset available to be claimed (in canonical form),
  • amount - amount available to be claimed,
  • claimants - list of claimants with predicates (see below):
    • destination - destination account ID,
    • predicate - predicate required to claim a balance (see below).
• claim_claimable_balance with the following fields:
  • balance_id - unique ID of balance to be claimed,
  • claimant - account ID of a claimant.
• begin_sponsoring_future_reserves with the following fields:
  • sponsored_id - account ID for which future reserves will be sponsored.
• end_sponsoring_future_reserves with the following fields:
  • begin_sponsor - account sponsoring reserves.
• revoke_sponsorship with the following fields:
  • account_id - if account sponsorship was revoked,
  • claimable_balance_id - if claimable balance sponsorship was revoked,
  • data_account_id - if account data sponsorship was revoked,
  • data_name - if account data sponsorship was revoked,
  • offer_id - if offer sponsorship was revoked,
  • trustline_account_id - if trustline sponsorship was revoked,
  • trustline_asset - if trustline sponsorship was revoked,
  • signer_account_id - if signer sponsorship was revoked,
  • signer_key - if signer sponsorship was revoked.

New effects

• claimable_balance_created with the following fields:
  • balance_id - unique ID of claimable balance,
  • asset - asset available to be claimed (in canonical form),
  • amount - amount available to be claimed.
• claimable_balance_claimant_created with the following fields:
  • balance_id - unique ID of a claimable balance,
  • asset - asset available to be claimed (in canonical form),
  • amount - amount available to be claimed,
  • predicate - predicate required to claim a balance (see below).
• claimable_balance_claimed with the following fields:
  • balance_id - unique ID of a claimable balance,
  • asset - asset available to be claimed (in canonical form),
  • amount - amount available to be claimed,
• account_sponsorship_created with the following fields:
  • sponsor - sponsor of an account.
• account_sponsorship_updated with the following fields:
  • new_sponsor - new sponsor of an account,
  • former_sponsor - former sponsor of an account.
• account_sponsorship_removed with the following fields:
  • former_sponsor - former sponsor of an account.
• trustline_sponsorship_created with the following fields:
  • sponsor - sponsor of a trustline.
• trustline_sponsorship_updated with the following fields:
  • new_sponsor - new sponsor of a trustline,
  • former_sponsor - former sponsor of a trustline.
• trustline_sponsorship_removed with the following fields:
  • former_sponsor - former sponsor of a trustline.
• claimable_balance_sponsorship_created with the following fields:
  • sponsor - sponsor of a claimable balance.
• claimable_balance_sponsorship_updated with the following fields:
  • new_sponsor - new sponsor of a claimable balance,
  • former_sponsor - former sponsor of a claimable balance.
• claimable_balance_sponsorship_removed with the following fields:
  • former_sponsor - former sponsor of a claimable balance.
• signer_sponsorship_created with the following fields:
  • signer - signer being sponsored.
  • sponsor - signer sponsor.
• signer_sponsorship_updated with the following fields:
  • signer - signer being sponsored.
  • former_sponsor - the former sponsor of the signer.
  • new_sponsor - the new sponsor of the signer.
• signer_sponsorship_removed with the following fields:
  • former_sponsor - former sponsor of a signer.

predicate field

predicate field is a JSON representation of xdr.ClaimPredicate as defined in CAP-23 and is a requirement that needs to be satisfied to claim the balance. It is a recursive structure that can be represented in JSON using for example the following Golang struct:

type claimPredicateJSON struct {
	And           *[]claimPredicateJSON `json:"and,omitempty"`
	Or            *[]claimPredicateJSON `json:"or,omitempty"`
	Not           *claimPredicateJSON   `json:"not,omitempty"`
	Unconditional bool                  `json:"unconditional,omitempty"`
	AbsBefore     *time.Time            `json:"absBefore,omitempty"`
	RelBefore     *int64                `json:"relBefore,omitempty"`
}

Please refer to the Golang implementation for details.

The following issue shows how the Golang SDK will handle predicate creation: stellar/go#3000

RevokeSponsorshipOp

The RevokeSponsorshipOp requires users to build LedgerKey or a struct for signers sponsorship. Ideally SDKs should expose helpers that build a valid operation for users without require them to pass an XDR LedgerKey. See the following issue for more information stellar/go#3001 .

The following changes were recently merged to SEP-10:

• [] the Manage Data operation's key includes a homeDomain FQDN instead of the anchorName string
• [] a SIGNING_KEY attribute in the stellar.toml of the service implementing SEP-10 is required
• [] client applications must match the value of the Manage Data operation's key with the home domain used in the request for the service's TOML file
• [] client applications must verify that the service's SIGNING_KEY keypair was used to sign the challenge transaction

Each SDK must update to enable the first and ideally third item in this list.

The SDF's JavaScript SDK released v5.0.5 recently including these changes.

The Go SDK may not support verifying the home domain from the Manage Data op key because it would require breaking changes to ReadChallengeTx() and other functions, compared to the strictly additive changes made to the JS SDK. If your SDK would also require breaking changes to implement this check, comment on this issue and we discuss the viability of different options.

If your SDK has implemented and released these changes, reference the release in a closing comment.

Because every version of stellar_flutter_sdk depends on crypto ^2.1.3 and google_fonts 2.1.0 depends on crypto ^3.0.0, stellar_flutter_sdk is incompatible with google_fonts 2.1.0.

And because no versions of google_fonts match >2.1.0 <3.0.0, stellar_flutter_sdk is incompatible with google_fonts ^2.1.0.

Is there any way I can become part of the contributors ? I will be working with this library and I'd like to be part of the team if that's possible. Let me know.

I'm trying to cleanup some old test accounts. Now when I run

RevokeSponsorshipOperationBuilder().revokeEd25519Signer(..., ...);

in a transaction I'm getting the code op_does_not_exist. Is this not completely implemented yet?

The payment stream only works for a short amount of time.. If I open the stream and I execute 4 payments in a row one after another it shows all the 4 transactions. But if I wait for a couple of minutes the executable of the code example below just crashes/stops working.

When listening to the stream via laboratory and the JavaScript SDK everything works fine. They both keep the connection open for as long as I wish tried 10 minutes even and it was no problem the transactions still showed up. Only somehow the Dart stream seems to crash or quit..

Dart code (not working when starting, waiting a couple of minutes and then execute a transaction):

Future<void> main() async {
  // Create a server instance
  StellarSDK sdk = StellarSDK.TESTNET;

  final completer = Completer<void>();

  // Listen to the stream for account changes
  sdk.payments
      .forAccount('GA7S6R5RWAQUIWESLLLZC23IFENBB6BBGUSJGFBWXFSZIB5MXEWZ6CP3')
      .cursor('1350672725331969')
      .order(RequestBuilderOrder.ASC)
      .stream()
      .doOnCancel(() {
    print("Stream cancelled");
    completer.complete();
  }).doOnError((error, stackTrace) {
    print("Error in stream: $error");
  }).listen(
    (operationResponse) {
      print('');
      print("##################################");
      print("### ${operationResponse.transactionHash} received ###");
      print("##################################");
    },
    onError: (error) {
      print("Error in stream: $error");
    },
  );

  await completer.future;
}

JavaScript (working fine even after its been idle for 10 minutes+):

var StellarSdk = require('stellar-sdk');
var server = new StellarSdk.Server('https://horizon-testnet.stellar.org');

var accountHandler = function (operationResponse) {
    console.log("");
    console.log("##################################");
    console.log("### " + operationResponse.transaction_hash + " received ###");
    console.log("##################################");
    console.log("");
};
var accountId = "GA7S6R5RWAQUIWESLLLZC23IFENBB6BBGUSJGFBWXFSZIB5MXEWZ6CP3";
var es = server.payments().forAccount(accountId).cursor('1350672725331969').order("asc").stream({
    onmessage: accountHandler
});

console.log("Stream started");

SDKs need to be updated to adapt to breaking changes that have occurred since Preview 11 (i.e. the current testnet release candidate) coming to Protocol 20.

Summary of Breaking Changes

This is likely irrelevant to SDK maintainers, but do note sandbox mode has been removed from the Soroban CLI (stellar/stellar-cli#983).

XDR

The XDR needs to be updated to stellar/stellar-xdr@6a620d1. This includes a non-trivial list of breaking changes (mostly renames):

• The BumpFootprintExpirationOp is now ExtendFootprintTTLOp and its ledgersToExpire field is now named extendTo, but it serves the same purpose.
• ContractExecutable.contractExecutableToken is now contractExecutableStellarAsset
• SorobanTransactionData.refundableFee is now resourceFee
• This new fee encompasses the entirety of the Soroban-related resource fees. Note that this is distinct from the "network-inclusion" fee that you would set on your transaction
• see stellar/js-stellar-base#704 for an example migration

RPC

• The getEvents RPC endpoint structure has changed:
  • value: { xdr: string } is now just value: string (stellar/stellar-cli#1015)
  • contractId will always be a contract strkey (C... format) if present (stellar/stellar-cli#1007)
• The getLedgerEntries RPC endpoint now includes expiration info (stellar/stellar-cli#1010):
  • expirationLedgerSeq is a string-ified uint32 present if the requested entries have expiration

SEP-10 3.1 Support

TL;DR

Implement the changes described the SEP-10 3.1 commit.

This likely involves adding an optional argument to the SEP-10 utility functions for adding an additional Manage Data operation containing the domain of the SEP-10 server (web_auth_domain).

Background & Description

Thank you for implementing SEP-10 v3.0, which reintroduced verification of the home domain of the service requiring SEP-10 authentication, ensuring that signed challenges cannot be used for any other service.

SEP-10 v3.1 adds an optional Manage Data operation that includes the home domain of the service issuing SEP-10 challenges. This allows clients and servers to verify the issuer of the challenge.

Protocol 19 SDK Support

Once voted in, the release of Protocol 19 will introduce two new CAPs:

• CAP-21, which introduces new transaction validity preconditions, and
• CAP-40, which introduces a new type of signer: signed payloads

API Changes

Horizon will return new fields for both accounts and transactions:

Accounts

Account records can now contain two new, optional fields:

"sequence_ledger": 0, // uint32 ledger number
"sequence_time": "0"  // uint64 unix time in seconds, as a string

The absence of these fields indicates that the account hasn't taken any actions since prior to the Protocol 19 release. Note that they'll either be both present or both absent.

Transactions

Each transaction record can now contain the following optional object:

"preconditions": {
  "timebounds": {
    "min_time": "0",  // uint64 unix time in seconds, as a string
    "max_time": "0"   // as above
  },
  "ledgerbounds": {
    "min_ledger": 0,  // uint32 ledger number
    "max_ledger": 0   // as above
  },
  "min_account_sequence": "0",          // int64 sequence number, as a string
  "min_account_sequence_age": "0",      // uint64 unix time in seconds, as a string
  "min_account_sequence_ledger_gap": 0, // uint32 ledger count

  "extra_signers": [] // list of signers as StrKeys
}

All of the top-level fields within this object are also optional. However, the "ledgerbounds" object will always have its inner values set.

Note that the existing "valid_before_time" and "valid_after_time" fields on the top-level object will be identical to the "preconditions.timebounds.min_time" and "preconditions.timebounds.min_time" fields, respectively, if those exist. The "valid_before_time" and "valid_after_time" fields are now considered deprecated and will be removed in Horizon v3.0.0.

StrKey Changes

The specification for CAP-40's new signed payload signers is outlined in this SEP-23 change: stellar/stellar-protocol#0943c19e. In summary, it should be prefixed with a P, then encode the signer address followed by the payload in typical XDR fashion.

Keypair Changes

It should be possible to create decorated signature hints from signed payloads as described in CAP-40.

Transaction Builder Changes

SDKs should allow transactions to be built with the new preconditions:

• ledger bounds
• minimum account sequence number
• minimum account sequence age
• minimum ledger-gap from the account sequence
• extra signers

Refer to CAP-21 for the details on their intended functionality.

For handling timebounds, we recommend the following pattern:

• If a transaction only has a timebound set, set the PRECOND_TIME XDR structure
• If the transaction has other preconditions set, set the PRECOND_V2 XDR structure

This provides both backwards compatibility and future efficiency. Note that SDKs typically require that timebounds be set on a transaction. Omitting timebounds must be done explicitly, e.g. by doing .setTimeout(TIMEOUT_INFINITE) in the JavaScript SDK.

Signers should be represented as their human-readable StrKey strings, but should decode to (and encode from) SignerKey XDR instances.

Reference Implementations

There are three reference implementations authored by SDF:

• Go: stellar/go#4261
• Java: lightsail-network/java-stellar-sdk#409
• JavaScript: stellar/js-stellar-sdk#763

You can follow each respective issue to its implementation PRs.

Hi there,

when will the null safety version available?

Thanks

Thank you very much for the great work!

I have a question regarding how to handle the notification when the payment is received?

TL;DR

Add opt-in support for SEP 23. SEP23 adds a strkey representation (M-strkeys) for MuxedAccounts.

For example, given the MuxedAccount MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26 , you might get the following fields:

source_account: GAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSTVY
source_account_muxed: MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26
source_account_muxed_id: 1234

It should be implemented as an opt-in feature

SEP23 is still a Draft. We plan to (at least initally) use the M-strkey representation to explore the use of Muxed Accounts. Later on, we me consider it stable and enable it by default.

As such, it's critical to make M-strkeys an opt-in feature (e.g. only usable by the user through am explicitly enabled flag or other mechanisms).

In particular, no user should be enabling M-addresss unknowingly, either for new or existing code (e.g. through an SDK update).

Recent SEP23 representation change

If you were already familiar with SEP23, it's worth noting that the encoding ordering changed recently at stellar/stellar-protocol#895

The SEP 23 specification already contains that modification.

Reference implementation

You can use the Go SDK implementation as a reference: stellar/go#3527

In the Go SDK we have one entry point into generating transaction envelopes, NewTransaction() . We added a configuration parameter to NewTransaction() which toggles support for muxed accounts. If NewTransaction() is configured with muxed account support then it will interpret "M..." address strings as muxed accounts at the xdr level. However, if NewTransaction() is configured to disable muxed accounts, whenever an "M..." address is provided we will extract the underlying "G..." address from and use that at the XDR level.

We followed a similar approach for the other entry points of the SDK (namely TransactionFromXDR() and NewFeeBumpTransaction()).

The code to reproduce the issue.

final sdk = StellarSDK.TESTNET;
final network = Network.TESTNET;

final sourceKeyPair = KeyPair.fromSecretSeed(
  "SAW74SJ4ERDAKW4GSL63ASQAN7EVFCI4A44JMRKPPGAP6ROGPBL6SN3J",
  // GAS4N4UW4CU24AIVQIIGDW6ENUYZUVZ7Z3MH5GVYGQHVKXLJ2GBDP6RQ
);

await FriendBot.fundTestAccount(sourceKeyPair.accountId);

final createClaimableBalanceBuilder = CreateClaimableBalanceOperationBuilder(
  [
    Claimant(
      sourceKeyPair.accountId,
      Claimant.predicateNot(
        Claimant.predicateBeforeRelativeTime(60),
      ),
    )
  ],
  Asset.NATIVE,
  "100",
);

final sourceAccount = await sdk.accounts.account(
  sourceKeyPair.accountId,
);

final transactionBuilder = TransactionBuilder(sourceAccount)
  ..addOperation(createClaimableBalanceBuilder.build());

final transaction = transactionBuilder.build()..sign(sourceKeyPair, network);

final result = await sdk.submitTransaction(transaction);

Hi,

is there any function / method to convert seed to Mnemonic?

Regards,

Ian

I wonder why these functions don't support async/await?

String mnemonic = Wallet.generate12WordsMnemonic(); Wallet wallet = Wallet.from(mnemonic); KeyPair keyPair = wallet.getKeyPair(index: 0);

Without the aysnc/await support, the app hangs when mnemonics and keys are generated.

Hi, am Christian From Zegital Development firm in Nigeria.
i just embarked on the journey of implementing and using Stellar for my clients apps
and i really need ur help in answering this one question.
Can my clients buy and store stable coins like usdt or usdc in there wallet? can they also have other assets like bitcoin and etherum? if yes please how to i go about this
i have started the development process already for the app, and also integrated Stellar sdk, i just need this questions aswered and directions, thanks

Hi,

I'm trying to add the single account stream only the EventSource class does not seem te work. You can see that I've added some unit test in the draft PR.

https://github.com/Soneso/stellar_flutter_sdk/pull/60/files

When I run this script while doing the unit test I do see the javascript stream to output the expected data. Only the stream in the unit test only shows the first account reponse event.

var StellarSdk = require('stellar-sdk');
var server = new StellarSdk.Server('https://horizon-testnet.stellar.org');

var accountHandler = function (accountResponse) {
    console.log("");
    console.log("################################");
    console.log("### accountResponse received ###");
    console.log("################################");
    console.log("");
    console.log(accountResponse);
};

var es = server.accounts().accountId("GDUIRZTI6VPHOUIFADD5QFRUVDSQ77K6VHAM76WYVTZ7UIQAR2LCXHFZ").stream({
    onmessage: accountHandler
});

console.log("Stream started");

Is this a known issue?

SEP-10 3.0

TL;DR

Implement the changes described in the SEP-10 v3.0 PR by November 13th. It adds a check for the correct homeDomain value in the SEP-10 challenge transaction. homeDomain is the domain hosting the SEP-1 stellar.toml containing a WEB_AUTH_ENDPOINT and SIGNING_KEY.

The SEP-10 v3.0 PR is not merged, but the only changes still in discussion relate to phrasing. No more functional changes will be introduced.

Background & Description

Thank you for implementing SEP-10 v2.1, this removed the possibility of unexpected SEP-10 client-anchor incompatibility. Now that Anchors have been given time to update, Wallets can soon expect the Anchors they interact with to have a v2.1 challenge. This means their challenge transactions include the home domain that hosts the SEP-1 stellar.toml that has the WEB_AUTH_ENDPOINT used to obtain the JWT.

The next step is for SDK's to release changes supporting SEP-10 v3.0, which adds the check for the expected homeDomain back to SEP-10. Wallets should upgrade only when their partner anchors have upgraded to v2.1. This should be the case for all anchors by the time your v3.0 change is released.

Deadline

The SDF asks all SDK's to release new versions including SEP-10 v3.0 support by November 13th. On Monday November 16th the SDF will announce to the ecosystem SDK support for SEP-10 v3.0.

final input = XdrDataInputStream(base64Decode("AAAAAAAAAGT/////AAAAAQAAAAAAAAAW/////AAAAAA="));
final result = XdrTransactionResult.decode(input);
debugPrint(result.toString());

Executing this returns a stack overflow exception:

When the exception was thrown, this was the stack: 
#0      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:673:3)
#1      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)
#2      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)
#3      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)
#4      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)
#5      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)
#6      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)
#7      XdrOperationResultTr.liquidityPoolDepositResult= (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:674:12)

The following changes to claimable balances, and assets endpoints were recently released in Horizon 2.2.0:

• The Asset object now includes the following new fields, with examples:

      ...
       "accounts": {
          "authorized": 23,
          "authorized_to_maintain_liabilities": 11,
          "unauthorized": 6
        },
        "num_claimable_balances": 3,
        "balances": {
          "authorized": "997268.0000000",
          "authorized_to_maintain_liabilities": "498634.0000000",
          "unauthorized": "249317.0000000"
        },
        "claimable_balances_amount": "124658.5000000",
        ...

• There is a new endpoint at /claimable_balances/{id}/operations{?cursor,limit,order}, to fetch operations for a given claimable balance.
• There is a new endpoint at /claimable_balances/{id}/transactions{?cursor,limit,order}, to fetch transactions for a given claimable balance.

Each SDK must update to support the first item in the list, so that the amount, and num_accounts fields can be deprecated in Horizon v3.
Each SDK should update to support querying operations and transactions for a given Claimable Balance ID.

The SDF's JavaScript SDK released v8.2.0 recently including these changes.

If your SDK has implemented and released these changes, reference the release in a closing comment.

Hello,

It seems that the timebounds in SEP-10 challenge transaction are checked incorrectly. The timebounds are expressed in seconds, but they are compared with currentTime variable, expressed in milliseconds, causing exception to be thrown.

It can be seen in debugger:

The relevant code is here:

The JS SDK does /1000 properly: https://github.com/stellar/js-stellar-sdk/blob/c09f8f5b789dd596531ba334fd0b9e19f0265933/src/utils.ts#L735

We've just released v6.0.1, of the SDF Javascript base library.

It includes changes to implement CAP-38, supporting automated market makers.

These changes will be released with the protocol v18 upgrade.

There are some further notes on the changes API endpoints, with mock responses, on this APIary. Further notes on the API changes are available in this document.

• Each SDK must update to enable depositing, and withdrawing from liquidity pools.
• SDKs must also update to include the new effect types, as well as new fields on Accounts.
• SDKs should also include methods to query liquidity pool information.

Because the order of the assets must be sorted in the pool ID, as well as in the depositing and withdrawing operations, SDKs should either:

• error when creating a pool ID with assets in the wrong order
• or, automatically sort the assets when generating a pool ID and structure the SDK to help users avoid making this mistake. For example, in the Go SDK, we pass in each asset and amount as a tuple, so that they are associated.

Asset ordering is determined by:
Native < AlphaNum4 < AlphaNum12, then by Code, then by Issuer, using lexicographic ordering.

If your SDK has implemented and released these changes, reference the release in a closing comment.

SEP-10: Apply grace period to minTime constraint

It is possible that the client machine's clock is behind the SEP-10 server machine's clock.

If this is the case, client applications calling readChallengeTx() may not be able to validate the challenge due to the challenge transaction's minimum timebound being greater than the client machine's current time.

Changes

readChallengeTx() or the equivalent function

• Apply a 5-minute grace period to the minibum timebound check
  • i.e. the minimum timebound should be permitted to be at most 5 minutes in the future from the client machine's current time

Implementations

Both the JS and Go SDKs have been updated with these changes.

• stellar/js-stellar-sdk#667
  • The JS SDK also applied the grace period to the maximum timebound, but the minimum timebound is the more important constraint to relax.
• stellar/go#3824

SEP-10 Muxed Account & Memo Support

SEP-10 now supports authenticating users of shared, pooled, or omnibus Stellar accounts.

These users are either represented using a muxed account (an M... address) or a Stellar account (G...) accompanied by an ID memo.

Changes

buildChallengeTx() or the equivalent function

• Allow muxed accounts as client account parameter values
• Add a optional memo parameter that accepts a 64-bit integer representation and attach it to the challenge transaction returned
  • If your language does not support optional parameters, this may be a breaking change
• Disallow muxed client accounts and memos to be passed in the same call; they are mutually exclusive parameters

readChallengeTx() or the equivalent function

• Allow muxed accounts as source accounts of the first operation within challenge transactions
• Add a 64-bit integer representation memo to the return value if present in the challenge transaction
  • Depending on the data type of the return value, this may be a breaking change
• Disallow muxed client accounts and memos to be present in the challenge transaction; they are mutually exclusive

Implementations

The JS and Python SDKs have implemented this functionality, please use them as references:

• (stellar/js-stellar-sdk#709)[https://github.com/stellar/js-stellar-sdk/pull/709] included in release v8.3.0
• (StellarCN/py-stellar-base#521)[https://github.com/StellarCN/py-stellar-base/pull/521] included in release v4.2.0

Because every version of stellar_flutter_sdk depends on http ^0.12.0+3 and mayan depends on http ^0.13.3, stellar_flutter_sdk is forbidden.

have been following the whole guild on flutter but still cant figure out how to create a buy offer for already existing tokens like bitcoin, ethereum,xrp and others, please i need a guide on these

Hello
I have faced an issue: I can not get Selling and Buying asset's code from offers of an account.
For example, I have created an offer from native to BTC. When I load the offers, there is no property to get the asset's code.
Please check this
Thanks

Hi,

I would like to know if there is any function which I can use to validate seed, inputted manually by user?

Regards,

Ian

When closing this issue, please respond with at least the GitHub release that supports Protocol 20.

Protocol 20: Soroban

The next version of the Stellar network will feature a new smart contract platform called Soroban. Note that this version features only additive changes: existing operations, etc. have not changed. (Protocol 20 will be the same thing as "Preview 11," the latest release of Soroban to Stellar Futurenet.)

New XDR Schema

• Your SDK should support encoding and decoding the new XDR schemas. The network protocol will use the XDR schema defined here: stellar-xdr @ 9ac0264.
• There are three new operations. The former is for invoking contract actions, while the latter two are related to state expiration (see Interacting with Soroban via Stellar and State Expiration):
  • invokeHostFunctionOp takes a function to invoke (e.g. contract creation, uploads, method invocation) and the corresponding authorization to perform that action (JS reference: )
  • bumpExpirationFootprintOp, which takes a ledgersToExpire and bumps the expiration ledger of the ledger keys specified in the transaction
  • restoreFootprintOp restores the expiration of the ledger keys specified in the transaction
  • Notice that the latter two have no parameters to describe what ledger entries are bumping or restoring. This is because they reference the transaction-level Soroban data access pattern, which is a bit of a paradigm shift of the "all-inclusive" operations we've seen before.
• Ideally, it should also provide abstractions for various high-profile components of building Soroban applications. You can use the JavaScript SDKs for references, though these are likely not idiomatic, and may change in the near future as use-cases are better understood. These are in relative order of priority:
  • a way to add xdr.SorobanTransactionData to a transaction when building it, which is a data structure that describes the resource usage of a Soroban transaction (see Transaction resources), including its storage access footprint, memory usage, etc. (JS reference: SorobanDataBuilder)
  • support for contract addresses in StrKey format (see SEP-23; JS reference: StrKey.encodeContract)
  • a way to represent contract objects and convert them to addresses (see Contract-specific Authorization, which demonstrates that an address can either be an account ID [G...] or a contract ID [C...]; JS reference: Contract and Address)
  • conversion to and from language-native values to the smart contract values (xdr.ScVal) used by Soroban (see Primitive Types; JS reference: scValToNative, scValToBigInt, nativeToScVal, and ContractSpec)
  • abstractions to perform multi-party authentication of contract invocations (see Authorization; JS reference: authorizeInvocation and authorizeEntry)

You may also want to look into how the TypeScript bindings are generated (code link) via the new soroban command line tool and add a generator for your particular language.

New client libary: Soroban RPC

• Unlike Horizon, Soroban RPC uses JSON-RPC as its transport mechanism
• The methods are all documented here: https://soroban.stellar.org/api/methods
• You can use https://rpc-futurenet.stellar.org/ for testing or connect to the network with your own instance (see the RPC docs)

Horizon API

The following APIs have changed:

• /effects can produce two new effects:
  • contract_credited occurs when a Stellar asset moves into its corresponding Stellar Asset Contract instance
  • contract_debited occurs when a Stellar asset moves out of its corresponding Stellar Asset Contract instance
• /assets/:name contains two new fields:
  • num_contracts - the integer quantity of contracts that hold this asset
  • contracts_amount - the total units of that asset held by contracts
• /operations has three new response schemas corresponding to the Soroban operations (described above):

// when type: 'invokeHostFunction'
{
    function: string;
    parameters: { value: string, type: string }[];
    address: string;
    salt: string;
    asset_balance_changes: {
        asset_type: string;
        asset_code?: string;
        asset_issuer?: string;

        type: string;
        from: string;
        to: string;
        amount: string;
    }[];
}
// when type: 'bumpFootprintExpiration':
{
    ledgers_to_expire: number;
}
// when type: 'restoreFootprint':
{
    // empty
}

SDF Reference Implementations

• JavaScript: low-level XDR structures, RPC API, Horizon API (note that there is no requirement to split out the APIs in this way: it's a case-by-case language/design choice)
• Golang
• Java
• Python

Hello,
With the 1.2.6 SDK, I'm trying following code to obtain JWT from nTokens staging server:

    const anchorDomain = 'staging.ntokens.com';
    final toml = await StellarToml.fromDomain(anchorDomain);

    final webAuth = WebAuth(
      toml.generalInformation?.webAuthEndpoint,
      Network.TESTNET,
      toml.generalInformation?.signingKey,
      anchorDomain,
    );

    final jwt = await webAuth.jwtToken(accountId, [keypair]);

and while equivalent code works on backend (JS SDK), I'm receiving error from

{\"detail\":\"Unsupported media type \\"text/plain; charset=utf-8\\" in request.\"}

Can you please make sure that the Flutter SDK works with the nTokens server? I'm not sure if the problem is on the Flutter SDK side, or nTokens are too restrictive.

I just upgraded to the latest version of flutter and there seems to be some syntax errors being detected when trying to build, I am quite sure, it is due to the old version of the toml package used.

Is there any specific reason why it's not updated?

Current Version: toml: ^0.11.0
New Version: toml: ^0.13.1

Hi,
I try to use stellar_flutter_sdk in flutter web.
the code simply call KeyPair.random().

I got this exception:

══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
The following RangeError was thrown building MyApp(dirty):
max must be in range 0 < max ≤ 2^32, was 0

The relevant error-causing widget was:
  MyApp file:///Users/x/y/z/lib/main.dart:5:10

When the exception was thrown, this was the stack:
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 214:49  throw_
dart-sdk/lib/_internal/js_dev_runtime/patch/math_patch.dart 314:7             nextInt
packages/tweetnacl/src/tweetnacl_base.dart 3150:27                            randombytes_array_len
packages/tweetnacl/src/tweetnacl_base.dart 3139:12                            randombytes_array
packages/tweetnacl/src/tweetnacl_base.dart 3143:12                            randombytes
packages/stellar_flutter_sdk/src/key_pair.dart 176:46                         random

that was using Chrome (web), ddc runtime.
the functionality has no problem on the Android emulator.

my pubspec.yaml:

  stellar_flutter_sdk: ^1.0.4

I saw both packages stellar_flutter_sdk and tweetnacl, has flutter web badge support.

thoughts?

thank you.

Upcoming Soroban RPC Change

The v20.1.0 version of Soroban RPC introduces the following additive change:

• soroban-tools#1131

Which changes the request schema for the simulateTransaction endpoint, adding the optional resourceConfig parameter, which, for now, contains a single field:

{
  "transaction": "<base64-encoded transaction>",
  "resourceConfig" {
    "instructionLeeway": 0   // <number of add'l CPU instructions to reserve>
  }
}

Though this is an optional parameter, it may require an update depending on how you were submitting the request via JSON-RPC previously. Namely, optional parameters are treated differently depending on whether or not you are POSTing with an object (i.e. params: { transaction: "..." }) or an array (i.e. params: [ "..." ]). In the latter case, the optional parameter will not be honored and the request will be met with the following error:

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32602,
    "message": "invalid parameters",
    "data": "[-32602] got 1 parameters, want 2"
  }
}

• Please update your SDK to use object-based parameter passing in JSON-RPC (if necessary) and allow users to optionally specify this additional CPU instruction leeway parameter.
• Please also note the set of breaking schema changes that occurred in the stable Protocol 20 release, described here.

Reference implementation

• JavaScript: js-stellar-sdk#896 (released in v11.1.0).

This issue lists the changes to the Horizon API introduced by CAP-35. This CAP comprises the public-facing changes in Stellar Protocol 16. The first Horizon version with the updated API is Horizon 2.1.0.

This protocol upgrade is purely additive. We expect a protocol 16 compliant SDK to be able to run successfully against a protocol 16 network.

We are aiming for the following tentative timeline:

March 30: Horizon released with protocol 16 support (done)
Begining of April: Core release with protocol 16 support
May: Protocol 16 deployed to Testnet
June: Protocol 16 Prodnet-deployment vote

New objects

None

Modified objects

• Claimable Balance

  • Claimable balance flags have been incorporated (by bumping it's XDR extension version to v1). For now there's only a possible flag (CLAIMABLE_BALANCE_ENABLED_FLAG)

• Trustline

  • A new flag as been added (AUTH_CLAWBACK_ENABLED_FLAG)

New endpoints

None

Modified endpoints

None

New Operations

• clawback with the following fields:

  • Asset fields (identical to the asset fields in the Change Trust, Allow Trust and Set Trustline Flags operations)
    • asset_type
    • asset_code
    • asset_issuer
  • from - account from which the asset is clawed back
  • amount - asset amount clawed back

• clawback_claimable_balance, with the following fields:

  • balance_id - claimable balance identifer of the claimable balance to be clawed back

• set_trust_line_flags, with the following fields:

  • Asset fields (identical to the asset fields in the Change Trust, Allow Trust and Set Trustline Flags operations)
    • asset_type
    • asset_code
    • asset_issuer
  • trustor - account whose trustline is affected by this operation
  • flag fields, with the same scheme as the Set Options operation (note that CAP-35 introduces the new AUTH_CLAWBACK_ENABLED_FLAG flag)
    • set_flags - array containing the integer (XDR) representation of the flags to enable
    • set_flags_s - array containing the textual representation of the flags in set_flags (possible values are: authorized, authorized_to_maintain_liabilites and clawback_enabled)
    • clear_flags - array containing the integer (XDR) representation of the flags to disable
    • clear_flags_s - array containing the textual representation of the flags in clear_flags (possible values are: authorized, authorized_to_maintain_liabilites and clawback_enable)

New effects

• trustline_flags_updated, with the following fields:

  • Asset fields (like explained in the operations above):
    • asset_type
    • asset_code
    • asset_issuer
  • trustor - account whose trustline the effect refers to
  • authorized_flag - true to indicate the flag is set, field ommited if not set
  • authorized_to_maintain_liabilites - true to indicate the flag is set, field ommited if not set
  • clawback_enabled_flag - true to indicate that the flag is set, field ommitted if not set

• claimable_balance_clawed_back, with the following fields:

  • balance_id - claimable balance identifer of the claimable balance clawed back

Deprecations

• Operation allow_trust is deprecated in favor of set_trust_line_flags (although it will still be supported by the network)

• Effects trustline_authorized, trustline_authorized_to_maintain_liabilities and trustline_deauthorized are deprecated
  in favor of trustline_flags_updated. Note how we intentionally didn't add a new trustline_authorized_clawback_enabled effect.

  For uniformity, the allow_trust operation will start producing trustline_flags_updated from this release.

  For now trustline_authorized, trustline_authorized_to_maintain_liabilities and trustline_deauthorized will continue to be emitted as a result of the allow_trust operation
  but in the future we may stop doing so.

When processing an HTTP response with a 429 (Too Many Requests) status code, the SDK's internal handleResponse function attempts to throw a TooManyRequestsException. This exception expects a retry-after header to set the _retryAfter property. However, if the response lacks the retry-after header, the SDK generates a Null check operator used on a null value exception due to the null assertion on the retry-after header value. This behaviour might lead to unexpected errors for developers using the SDK.

Steps to Reproduce:

• Trigger a request resulting in a 429 status code response without the retry-after header using the SDK's public-facing functions.
• Observe the "Null check operator used on a null value" exception.

Expected Behavior:
The SDK should handle a 429 status code, regardless of the retry-after header's presence or absence.

Actual Behavior:
The SDK raises a null assertion error due to the absent retry-after header.

Suggested Fix:

• Make the _retryAfter property nullable and manage cases where the retry-after header is not present.

I get
"Unsupported operation: Int64 accessor not supported by dart2js."
When trying to sign an transaction using example at:
https://github.com/Soneso/stellar_flutter_sdk/blob/master/documentation/sdk_examples/send_native_payment.md
Error is in browser_client.dart, row 58 in http lib
completer.complete(StreamedResponse(

Using Flutter 2.5.1
stellar_flutter_sdk: ^1.2.1
Visual Studio Code 1.60.1 on Windows 10.
Flutter extension: 3.26.0

Using Network.TESTNET and StellarSDK.TESTNET;
Fetching account information works but not signing a transaction.
Have created and funded two separate accounts on TESTNET just to test but without luck.
Tested the same transaction with Stellar Laboratory and it works.
Fairly new to flutter but have done a couple of project using the go client for Stellar.

Hi!
I use KeyPair.fromAccountId(accountId) to get key pair.
But i can't sign transaction with this keypair.
How can i sign xdr with another account id?

after running the example code to create account i keep getting this error...

E/flutter (28206): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Error response from the server. Code: 404 - Body: {
E/flutter (28206):   "type": "https://stellar.org/horizon-errors/not_found",
E/flutter (28206):   "title": "Resource Missing",
E/flutter (28206):   "status": 404,
E/flutter (28206):   "detail": "The resource at the url requested was not found.  This usually occurs for one of two reasons:  The url requested is not valid, or no data in our database could be found with the parameters provided."

Muxed accounts (introduced into the protocol in CAP-27 and defined in its string form in SEP-23) should now be supported by default. Previously, we asked that they be hidden behind an opt-in feature flag; now, they should always be supported.

The following fields are muxed accounts and can thus be either a standard G... or a muxed M... address:

• FeeBumpTransaction.feeSource
• Transaction.sourceAccount
• Operation.sourceAccount
• Payment.destination
• PathPaymentStrictReceive.destination
• PathPaymentStrictSend.destination
• AccountMerge.destination
• Clawback.from

While the list above should be comprehensive, you can always refer to the XDR for an authoritative source of truth.

Refer to the following releases for reference implementations:

• Go: [email protected]
• JavaScript: [email protected] and [email protected]
• Java: [email protected]
• Python: [email protected]

Additional documentation is available in the glossary.

SDKs need to be updated to adapt to breaking changes that have occurred since Preview 11 (i.e. the current testnet release candidate) coming to Protocol 20.

Summary of Breaking Changes

This is likely irrelevant to SDK maintainers, but do note sandbox mode has been removed from the Soroban CLI (stellar/stellar-cli#983).

XDR

The XDR needs to be updated to stellar/stellar-xdr@6a620d1. This includes a non-trivial list of breaking changes (mostly renames):

• The BumpFootprintExpirationOp is now ExtendFootprintTTLOp and its ledgersToExpire field is now named extendTo, but it serves the same purpose.
• ContractExecutable.contractExecutableToken is now contractExecutableStellarAsset
• SorobanTransactionData.refundableFee is now resourceFee
• This new fee encompasses the entirety of the Soroban-related resource fees. Note that this is distinct from the "network-inclusion" fee that you would set on your transaction
• see stellar/js-stellar-base#704 for an example migration

RPC

• The getEvents RPC endpoint structure has changed:
  • value: { xdr: string } is now just value: string (stellar/stellar-cli#1015)
  • contractId will always be a contract strkey (C... format) if present (stellar/stellar-cli#1007)
• The getLedgerEntries RPC endpoint now includes expiration info (stellar/stellar-cli#1010):
  • expirationLedgerSeq is a string-ified uint32 present if the requested entries have expiration

Hi,
I'm getting this exception after withdraw request when trying to deposit to anchor.

Exception: Bad state: Cannot set the body fields of a Request with content-type "application/json".
E/flutter ( 8436): #0 Request.bodyFields= (package:http/src/request.dart:133:7)
E/flutter ( 8436): #1 BaseClient._sendUnstreamed (package:http/src/base_client.dart:87:17)
E/flutter ( 8436): #2 BaseClient.post (package:http/src/base_client.dart:32:7)
E/flutter ( 8436): #3 StellarSDK.submitTransactionEnvelopeXdrBase64 (package:stellar_flutter_sdk/src/stellar_sdk.dart:160:10)
E/flutter ( 8436): #4 StellarSDK.submitTransaction (package:stellar_flutter_sdk/src/stellar_sdk.dart:141:12)

Asset asset = AssetTypeCreditAlphaNum4('SRT' , issuer);

Transaction transaction = TransactionBuilder(sender) .addOperation(PaymentOperationBuilder( withdrawAnchorAccount, asset,'100') .build()).addMemo(MemoHash(base64Decode(withdrawMemo))) .build();

transaction.sign(keyPair,Network.TESTNET);
SubmitTransactionResponse submitTransactionResponse = await StellarSDK.TESTNET.submitTransaction(transaction);

TL;DR

The SEP-10 protocol has been updated to relax the requirements of the single Manage Data operation included in SEP-10 challenge transactions, and should be implemented by October 21st. On this date the SDF will announce the SDK updates to Anchors and Wallets, urging them to update as soon as possible.

Background

To provide context, the SEP-10 2.0 changes replaced SEP-10 challenges' Manage Data operation anchorName key with a home_domain key. However, we quickly realized there was confusion and misunderstanding about the value of the home_domain parameter introduced in most SDKs earlier. Specifically, some users of the SDK believe the home_domain value is the home domain used to request the SEP-10 challenge, while others believe it is the home domain that requires the JWT authentication token.

This is problematic because SDK's implemented equality checks on the home_domain value of the Manage Data operation, so mismatched domains would result in client-server (wallet-anchor) incompatibility.

SEP-10 2.1.0 Changes

The following changes have been made to the SEP-10 protocol:

• Clients are no longer required to validate the home_domain value in a SEP-10 challenge's first Manage Data operation
• SEP-10 challenge transactions may now have additional Manage Data operations as long as the source account of the operation is the SEP-10 server's SIGNING_KEY
  • Note: additional Manage Data operations will be added in future changes, so any added Manage Data operations added by the issuer of the challenge will need to come after the Manage Data operations defined in this document

References

SEP-10 2.1.0 Changes
Go SDK SEP-10 2.1.0 Support
JavaScript SDK SEP-10 2.1.0 Support

Looking Forward

Soon after SEP-10 2.1.0 is implmenented and announced, the SDF will ask SDK's to upgrade to SEP-10 3.0, but no action needs to be taken for this yet.

We are seeing a lot of errors in our crashlytics.. First I thought it has to do with bad signal but we never see any issue/exceptions with our Dio requests.. I wonder if you might have any ideas?

The following code throws an unknown enum value exception. Any ideas what I'm missing?

AbstractTransaction.fromEnvelopeXdrString('AAAAAgAAAABGmZyYeYjKxpmwZv1hTKWY5Uc5pzHr7Ld2Tg9KZlXJ2gAAnEAAA588AAAAAwAAAAAAAAABAAAACVBVUnxSVURZMgAAAAAAAAQAAAABAAAAAIw4P8JGqI0p0eawiPOSVAgxDEoyfX71XxIuCEWAAtgeAAAAEAAAAABGmZyYeYjKxpmwZv1hTKWY5Uc5pzHr7Ld2Tg9KZlXJ2gAAAAEAAAAAWN3OP2d8s6y4UvUHUsTnvMLoMY9GcBsYEZA/jVvq5l8AAAABAAAAAEaZnJh5iMrGmbBm/WFMpZjlRzmnMevst3ZOD0pmVcnaAAAAAlVTRFBFTkQAAAAAAAAAAABY3c4/Z3yzrLhS9QdSxOe8wugxj0ZwGxgRkD+NW+rmXwAAAAAF9eEAAAAAAQAAAABGmZyYeYjKxpmwZv1hTKWY5Uc5pzHr7Ld2Tg9KZlXJ2gAAAA4AAAACVVNEUEVORAAAAAAAAAAAAFjdzj9nfLOsuFL1B1LE57zC6DGPRnAbGBGQP41b6uZfAAAAAAX14QAAAAACAAAAAAAAAABGmZyYeYjKxpmwZv1hTKWY5Uc5pzHr7Ld2Tg9KZlXJ2gAAAAAAAAAAAAAAAFjdzj9nfLOsuFL1B1LE57zC6DGPRnAbGBGQP41b6uZfAAAAAwAAAAEAAAAEAAAAAGGedecAAAABAAAAAEaZnJh5iMrGmbBm/WFMpZjlRzmnMevst3ZOD0pmVcnaAAAAEQAAAAAAAAAA');

Exception:

[VERBOSE-2:ui_dart_state.cc(209)] Unhandled Exception: Exception: Unknown enum value: 1637774823
#0      XdrClaimPredicateType.decode (package:stellar_flutter_sdk/src/xdr/xdr_ledger.dart:136:9)
#1      XdrClaimPredicate.decode (package:stellar_flutter_sdk/src/xdr/xdr_ledger.dart:226:64)
#2      XdrClaimPredicate.decode (package:stellar_flutter_sdk/src/xdr/xdr_ledger.dart:236:57)
#3      XdrClaimPredicate.decode (package:stellar_flutter_sdk/src/xdr/xdr_ledger.dart:248:50)
#4      XdrClaimantV0.decode (package:stellar_flutter_sdk/src/xdr/xdr_ledger.dart:350:43)
#5      XdrClaimant.decode (package:stellar_flutter_sdk/src/xdr/xdr_ledger.dart:319:36)
#6      XdrCreateClaimableBalanceOp.decode (package:stellar_flutter_sdk/src/xdr/xdr_account.dart:1078:43)
#7      XdrOperationBody.decode (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:421:85)
#8      XdrOperation.decode (package:stellar_flutter_sdk/src/xdr/xdr_operation.dart:140:46)
#9      XdrTransaction.decode (package:stellar_flutter_sdk/src/xdr/<…>

Stellar Lab

With the introduction of Protocol 14 and specifically CAP-33, accounts can now be created without a starting balance when they are sponsored.

The CAP notes:

Operation Validity Changes
Any downstream system relying on the fact that CreateAccountOp is invalid if startingBalance = 0 will be affected.

This subtlety is easy to overlook, so please ensure that the SDK allows this updated constraint.

If this SDK validates the starting balance to prevent starting balances of zero, please update the SDK to allow it. When a transaction is submitted the Stellar network will ensure the amount is non-zero if it needs to be in the specific situations it is required, but SDKs should no longer require it for all cases.

Hello. How can I create a stellar anchor? I use dart. Im unable to create the anchor.

TL;DR

Add support for additional _muxed and _muxed_id optional fields in Horizon's JSON responses (available since Horizon 2.4, following what's described in SEP 23). That is:

Anyplace a MuxedAccount appears, if the account is of a multiplexed
type (currently just KEY_TYPE_MUXED_ED2551), two new fields are
added to the JSON.

• Base field name + _muxed is the strkey of the multiplexed account.

• Base field name + _muxed_id is the integer.

For example, given the MuxedAccount
MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26,
you might get the following fields:

    source_account: GAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSTVY
    source_account_muxed: MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26
    source_account_muxed_id: 1234

For instance, here's an /operations response with the new fields:

{
  "_links": {
    "self": {
      "href": "https://horizon.stellar.org/operations/?cursor=\u0026limit=10\u0026order=asc"
    },
    "next": {
      "href": "https://horizon.stellar.org/operations/?cursor=33818572492801\u0026limit=10\u0026order=asc"
    },
    "prev": {
      "href": "https://horizon.stellar.org/operations/?cursor=12884905985\u0026limit=10\u0026order=desc"
    }
  },
  "_embedded": {
    "records": [
      {
        "_links": {
          "self": {
            "href": "https://horizon.stellar.org/operations/12884905986"
          },
          "transaction": {
            "href": "https://horizon.stellar.org/transactions/3389e9f0f1a65f19736cacf544c2e825313e8447f569233bb8db39aa607c8889"
          },
          "effects": {
            "href": "https://horizon.stellar.org/operations/12884905986/effects"
          },
          "succeeds": {
            "href": "https://horizon.stellar.org/effects?order=desc\u0026cursor=12884905986"
          },
          "precedes": {
            "href": "https://horizon.stellar.org/effects?order=asc\u0026cursor=12884905986"
          }
        },
        "id": "12884905986",
        "paging_token": "12884905986",
        "transaction_successful": true,
        "source_account": "GAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSTVY",
        "source_account_muxed": "MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26",
        "source_account_muxed_id": 1234,
        "type": "payment",
        "type_i": 1,
        "created_at": "2015-09-30T17:15:54Z",
        "transaction_hash": "3389e9f0f1a65f19736cacf544c2e825313e8447f569233bb8db39aa607c8889",
        "asset_type": "native",
        "from": "GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ",
        "from_muxed": "MAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSAAAAAAAAAAE2LP26",
        "from_muxed_id": 1234,
        "to": "GAQAA5L65LSYH7CQ3VTJ7F3HHLGCL3DSLAR2Y47263D56MNNGHSQSTVY",
        "amount": "99999999959.9999700"
      }
    ]
  }
}   

Note the:

• "source_account_muxed" and "source_account_muxed_id" fields.
• "from_muxed" and "from_muxed_id" fields.

Also, note how, although the XDR destination address of the Payment operation is a Multiplexed Account, there are no to_muxed nor to_muxed_id fields in the response. This simply means that the XDR representation of the destination address is of type KEY_TYPE_ED25519 and not KEY_TYPE_MUXED_ED2551.

Exhaustive list of new fields

• transactions objects: "account_muxed", "account_muxed_id", "fee_account_muxed" and "fee_account_muxed_id".
• operation objects: source_account_muxed and source_account_muxed_id. Additional fields depending on the operation type:
  • "create_account" operation: "funder_muxed", "funder_muxed_id".
  • "payment", "path_payment_strict_receive" and "path_payment_strict_send" operations: from_muxed, from_muxed_id, to_muxed and to_muxed_id.
  • "change_trust" operation: "trustor_muxed" and "trustor_muxed_id".
  • "allow_trust" operation: "trustee_muxed" and "trustee_muxed_id".
  • "account_merge" operation: "account_muxed", "account_muxed_id", "into_muxed", and "into_muxed_id".
  • "claim_claimable_balance" operation: "claimant_muxed" and "claimant_muxed_id".
  • "end_sponsoring_future_reserves" operation: "begin_sponsor_muxed", "begin_sponsor_muxed_id".
  • "clawback" operation: "from_muxed", "from_muxed_id".
• effect objects: "account_muxed", "account_muxed_id". Additional fields depending on the effect type:
  • "trade" effect: "seller_muxed" and "seller_muxed_id".

Reference implementation

You can use the Go SDK implementation as a reference:

• stellar/go#3603
• stellar/go#3610
• stellar/go#3626

Hi 👋 It would be very nice to have the package support Flutter 2 and have it migrated to null-safety

SEP-10 Client Attribution Support

A web service requiring SEP-10 authentication may want to attribute each HTTP request made to it to a specific client software. For example, a web service may want to offer reduced fees for the users of a specific client.

SEP-10 client attribution, detailed in the protocol specification, adds support for this capability.

Changes

The following changes are required to support this functionality:

• Building the challenge transaction:
  • Add client_domain (clientDomain) and client_signing_key (clientSigningKey) optional parameters
  • Adding a ManageData operation with 'client_domain' as the key and the client_signing_key parameter value as the value if these parameters are passed
• Verifying the challenge transaction:
  • Checking for a ManageData op with 'client_domain' as the key and checking for a signature from the operation's source account if present
  • Allowing the source of the 'client_domain' ManageData operation to not equal the server's account

For reference, the Python SDK has implemented the above changes.

Please implement and release a new version of the SDK with these changes, thank you!

hi,

I'm working on simple wallet application on flutter using stellar_flutter_sdk,
I'm following the official stellar-demo-wallet.

they encrypt the secret key with the public key and pin code.

any advice about how to get the Uint8List _mPrivateKey from KeyPair?
is there any possibility that the private key has getter in the next version?

thank you.