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 .

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

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.

Background

Create the API endpoints for the Transaction Resource.

https://www.stellar.org/developers/horizon/reference/resources/transaction.html

Endpoints

Resource Type Resource URI Template

• All Transactions Collection /transactions (GET)
• Post Transaction Action /transactions (POST)
• Transaction Details Single /transactions/:id
• Account Transactions Collection /accounts/:account_id/transactions
• Ledger Transactions Collection /ledgers/:ledger_id/transactions

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

Background

Create the API endpoints for the Account Resource.
https://www.stellar.org/developers/horizon/reference/resources/account.html

Endpoints

Resource Type Resource URI Template

• Account Details Single /accounts/:id
• Account Data Single /accounts/:id/data/:key
• Account Transactions Collection /accounts/:account_id/transactions
• Account Operations Collection /accounts/:account_id/operations
• Account Payments Collection /accounts/:account_id/payments
• Account Effects Collection /accounts/:account_id/effects
• Account Offers Collection /accounts/:account_id/offers

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.

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.

Something similar to the JS API, but in an idiomatic Elixir way. Thinking something closer to the token pattern and/or Ecto.Multi

Background

Create the API endpoints for the Payment Path Resource.

https://www.stellar.org/developers/horizon/reference/resources/path.html

Endpoints

Resource Type Resource URI Template

• Find Payment Paths Collection /paths

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.

Background

Create the API endpoints for the Data Resource.

https://www.stellar.org/developers/horizon/reference/resources/data.html

Endpoints

Resource Type Resource URI Template
! No endpoint listed on https://www.stellar.org/developers/horizon/reference/resources/data.html

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.

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.

We are using https://github.com/sunny-g/xdr. We must now define the types need to build transactions.

Types can be found here:
https://github.com/stellar/js-stellar-base/tree/master/xdr

Generated JS xdr (as an example) can be found here:
https://github.com/stellar/js-stellar-base/blob/master/src/generated/stellar-xdr_generated.js

Horizon 1.5.0 added a new field to the ledgers resource called tx_set_operation_count, if your SDK has support for /ledgers or ledger resources, then it should include this new field. The value can be a number or null.

This value represents the total number of operations in the transactions set. You can use it to find out if recent ledgers have been full (and therefore subject to surge pricing) or not.

Are you curious about other changes in Horizon?

My two picks are:

1. The removal of --ingest-failed-transactions flag, which means from now on Horizon will always ingest failed transactions. If you run your own Horizon, this might have an impact on your database.
2. A new experimental mode of doing database reingestion which uses a Stellar Core subprocess instead of a persistent Stellar Core database. Please give this a try and let us know if you find any issue!

You can see the full changelog in the release notes https://github.com/stellar/go/releases/tag/horizon-v1.5.0

There's still a few things left to do in order to make this repo an awesome place to contribute. Checklist as follows:

• Readme
  • Links to license
  • Links to Hex page for package (check out shields.io to link it up the fancy way)
• Is hooked up to a Slack channel somewhere so we get notified about issues/PRs
• Issue template (optional but encouraged) - http://wiki.revelry.co/index.php/Open_Source_Issue_Template

Background

Create the API endpoints for the Operation Resource.

https://www.stellar.org/developers/horizon/reference/resources/operation.html

Endpoints

Resource Type Resource URI Template

• All Operations Collection /operations
• Operations Details Single /operations/:id
• Ledger Operations Collection /ledgers/{id}/operations{?cursor,limit,order}
• Account Operations Collection /accounts/:account_id/operations
• Account Payments Collection /accounts/:account_id/payments

Background

Create the API endpoints for the Trade Aggregation Resource.

https://www.stellar.org/developers/horizon/reference/resources/trade_aggregation.html

Endpoints

Resource Type Resource URI Template

• Trade Aggregations Collection /trade_aggregations?{orderbook_params}

Add support for SEP 29. This is important to provide a simple way to protect users from forgetting memos when submitting payments to exchanges.

What would you like to see?

• Add server.checkMemoRequired(tx) with support for SEP0029.
  If any of the operations included in tx are of type payment, pathPaymentStrictReceive, pathPaymentStrictSend, or mergeAccount, then the SDK will load the destination account from Horizon and check if config.memo_required is set to 1 as defined in SEP0029.

  • While you could do the check in parallel, we decided to do a sequential check to avoid getting rate limited by SDF's public horizon which is used by default by many clients (read more here).

• Change server.SubmitTransaction to always check if memo is required.

• Allow the the check to be bypassed by setting skipMemoRequiredCheck to true, but default to requiring the check:

  server.SubmitTransaction(tx, {skipMemoRequiredCheck: true})
  

• The check should be skipped automatically if the transaction includes a memo.

You can use the following implementations as a reference:

• JS SDK: stellar/js-stellar-sdk#516
• Go SDK: stellar/go#2396

Refs: stellar/stellar-protocol#575

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.

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.

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

Erlang version: 22.1
Elixir version: 1.9.1
elixir-stellar-client version: 0.3.1

I'm getting the following error while compiling the dependencies with mix deps.compile:

could not compile dependency :crc, "mix compile" failed. You can recompile this dependency with "mix deps.compile crc", update it with "mix deps.update crc" or clean it with "mix deps.clean crc"
** (Mix) Could not compile with "make" (exit status: 2).
You need to have gcc and make installed. Try running the
commands "gcc --version" and / or "make --version". If these programs
are not installed, you will be prompted to install them.

I have both gcc and make installed and they're added properly in the PATH.

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()).

Background

Create the API endpoints for the Ledger Resource.

https://www.stellar.org/developers/horizon/reference/resources/ledger.html

Endpoints

Resource Type Resource URI Template

• All ledgers Collection /ledgers
• Single Ledger Single /ledgers/:id
• Ledger Transactions Collection /ledgers/:ledger_id/transactions
• Ledger Operations Collection /ledgers/:ledger_id/operations
• Ledger Payments Collection /ledgers/:ledger_id/payments
• Ledger Effects Collection /ledgers/:ledger_id/effects

The upcoming Horizon release is coming, and there are multiple breaking changes plus new features 🎉🎉🎉!

The following are the list of changes required to support this new release:

• ➕Update /fee_stats response.

  • ✂ Remove the following fields:

    min_accepted_fee
    mode_accepted_fee
    p10_accepted_fee
    p20_accepted_fee
    p30_accepted_fee
    p40_accepted_fee
    p50_accepted_fee
    p60_accepted_fee
    p70_accepted_fee
    p80_accepted_fee
    p90_accepted_fee
    p95_accepted_fee
    p99_accepted_fee

  • ➕Add support for max_fee and fee_charged fields. Each field contains a JSON object that looks like this:

    {
      "last_ledger": "22606298",
      "last_ledger_base_fee": "100",
      "ledger_capacity_usage": "0.97",
      "fee_charged": {
        "max": "100",
        "min": "100",
        "mode": "100",
        "p10": "100",
        "p20": "100",
        "p30": "100",
        "p40": "100",
        "p50": "100",
        "p60": "100",
        "p70": "100",
        "p80": "100",
        "p90": "100",
        "p95": "100",
        "p99": "100"
      },
      "max_fee": {
        "max": "100000",
        "min": "100",
        "mode": "100",
        "p10": "100",
        "p20": "100",
        "p30": "100",
        "p40": "100",
        "p50": "100",
        "p60": "100",
        "p70": "100",
        "p80": "100",
        "p90": "15000",
        "p95": "100000",
        "p99": "100000"
      }
     }

  See stellar/go#2140 for more info.

• ✂ Remove deprecated fee_paid field from Transaction response (replace it with the fee_charged and max_fee fields, see #1372).

• 🚨Multiple fields changed from int64 to string. If your SDK has types, they need to be updated. If possible, we recommend implementing backward compatibility support, as we did here.

  • Attribute offer_id in manage buy offer and manage sell offer operations.

  • Attribute offer_id in Trade effect.

  • Attribute id in Offer resource.

  • Attribute timestamp and trade_count in Trade Aggregation resource.

  See stellar/go#1609, stellar/go#1909, and stellar/go#1912 for more info

• 🚨 Update operation types to canonical names (if needed) (see stellar/go#2134).

• ➕Add support for /accounts end-point with ?signer and ?asset filters. We recommend a method like .accounts(queryParams) (see documentation for accounts).

• ➕Add support for /offers end-point with query parameters. We recommend a method like .offers(queryParams) (see documentation for offers).

• ➕Add support for /paths/strict-send end-point. See documentation.
  We recommend a method like

  strictSendPaths(sourceAsset, sourceAmount, [destinationAsset])
  

• ➕ Add support for /paths/strict-receive end-point. See documentation.
  We recommend a method like:

  strictReceivePaths(sourceAssets,destinationAsset, destinationAmount)
  

• ♻ Regenerate the XDR definitions to include MetaV2 support (also see #1902).

That's it! If you have any questions feel free to ping us on #dev-discussion in Keybase.

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!

Given I have created a transaction
When I want to be able to sign that transaction with one or more secret keys
Then I am returned a TransactionEnvelope that can be turned to XDR and posted using Transactions.post

Background

Create the API endpoints for the Operation Resource.

https://www.stellar.org/developers/horizon/reference/resources/operation.html

Endpoints

Resource Type Resource URI Template

• All Operations Collection /operations
• Operations Details Single /operations/:id
• Ledger Operations Collection /ledgers/{id}/operations{?cursor,limit,order}
• Account Operations Collection /accounts/:account_id/operations
• Account Payments Collection /accounts/:account_id/payments

Background

Create the API endpoints for the Offer Resource.

https://www.stellar.org/developers/horizon/reference/resources/offer.html

Endpoints

Resource Type Resource URI Template

• Account Offers Collection /accounts/:account_id/offers

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.

The vote to upgrade the Stellar network to Protocol 13 is currently scheduled for June 18 at 1600 UTC. Once Protocol 13 is enabled, we need to release a new version of the SDKs which implement the following tasks:

1) The SDKs should generate V1 transaction envelopes instead of V0 transaction envelopes.

After Protocol 13 is enabled Stellar Core will accept both V0 and V1 transactions in order to maintain backwards compatibility with transactions generated before Protocol 13 is enabled.

However, there are some features which are only available in V1 transactions such as CAP 18 Fine-Grained Control of Authorization. Therefore all SDKs should be generating V1 transactions once Protocol 13 is enabled.

Here is the Go SDK implementation for reference: stellar/go#2640

2) The SDKs should allow you to fee bump a V0 transaction. The workflow for fee bumping a V0 transaction is:

First convert the V0 transaction to a V1 transaction. This is possible because the transaction hash for a V0 transaction is the same for its equivalent V1 transaction.

Therefore, any signatures attached to a V0 transaction are also valid for the equivalent V1 transaction.

Once you have converted the V0 transaction into a V1 transaction, construct the fee bump transaction by wrapping the V1 transaction.

Here is the Go SDK implementation for reference: stellar/go#2650

The Go SDK has implemented these changes in a release branch. However, the release will only be published after the protocol vote because, until the network is upgraded, Stellar Core will only accept V0 transactions.

If you have any question, feel free to ping @tamirms or @abuiles.

Background

Create the API endpoints for the Effect Resource.

https://www.stellar.org/developers/horizon/reference/resources/effect.html

Endpoints

Resource Type Resource URI Template

• All Effects Collection /effects
• Single Effect Single /effects/:id
• Operation Effects Collection /operations/:id/effects
• Account Effects Collection /accounts/:account_id/effects
• Ledger Effects Collection /ledgers/:ledger_id/effects

Background

Create the API endpoints for the Orderbook Resource.

https://www.stellar.org/developers/horizon/reference/resources/orderbook.html

Endpoints

Resource Type Resource URI Template

• Orderbook Details Single /orderbook?{orderbook_params}
• Trades for Orderbook Collection /orderbook/trades?{orderbook_params}

Background

Create the API endpoints for the Page Resource.

https://www.stellar.org/developers/horizon/reference/resources/page.html

Endpoints

Any endpoint that provides a collection of resources will represent them as pages.

• Checklist item(s)?

Background

Create the API endpoints for the Trade Resource.

https://www.stellar.org/developers/horizon/reference/resources/trade.html

Endpoints

Resource Type Resource URI Template

• Trades Collection /trades

Stellar Protocol 13 is coming soon, and we need your help bringing support for it to your SDK.

The most relevant changes for SDKs are:

• CAP-0015 - Fee-Bump Transactions. This is the big one. The new operation requires a fundamental change to txenvelopes and means there are now two kinds of transactions, not one.
• CAP-0027 - First-class multiplexed accounts. Although full support for such accounts is not needed, the XDR changes are significant.
• CAP-0018 - Fine-Grained Control of Authorization. A new trustline flag and corresponding change to the Allow Trust operation.

This issue includes all the necessary changes to support Protocol 13, and gives you a path to release a new version of the SDK which is backwards compatible with the current version of the protocol (12). We suggest you aim to release such a backwards compatible version to allow seamless operation through the protocol vote.

For reference, SDF expects to update the testnet to Protocol 13 on 7 May 2020, and pubnet approximately a month after that.

1 - Update XDR

The first step to support Protocol 13 is to recreate your XDR definitions. You can use xdrgen to do that.

You can find the latest XDR definitions in the stellar-core repo.

2 - Update code which depends on TransactionEnvelope

The low-level representation for TransactionEnvelope changed from an xdr.Struct to an xdr.Union. That means you'll need to get the discriminant before reading its value.

/* A TransactionEnvelope wraps a transaction with signatures. */
union TransactionEnvelope switch (EnvelopeType type)
{
case ENVELOPE_TYPE_TX_V0:
    TransactionV0Envelope v0;
case ENVELOPE_TYPE_TX:
    TransactionV1Envelope v1;
case ENVELOPE_TYPE_TX_FEE_BUMP:
    FeeBumpTransactionEnvelope feeBump;
};

As listed above, a transaction envelope can contain a TransactionV0Envelope, a TransactionV1Envelope, or a FeeBumpTransactionEnvelope.

TransactionV0Envelope and TransactionV1Envelope are very similar, but differ in one attribute: the source account.

Next, let's explore how to handle each discriminant. We'll use js-stellar-base as a reference; however, implementation might change depending on your programming language.

TransactionV0Envelope and TransactionV1Envelope

Both v0 and v1 can be handled in the same wrapper class; we extended the Transaction class in js-stellar-base to do so. https://github.com/stellar/js-stellar-base/blob/a15fc74c1f5d37e1a2a94bd610990ccea62292bb/src/transaction.js

In the constructor, we check for the discriminant and throw an error if the envelope doesn't contain a v0 or v1 transaction.

const envelopeType = envelope.switch();
if (
  !(
    envelopeType === xdr.EnvelopeType.envelopeTypeTxV0() ||
    envelopeType === xdr.EnvelopeType.envelopeTypeTx()
  )
) {
  throw new Error(
    `Invalid TransactionEnvelope: expected an envelopeTypeTxV0 or envelopeTypeTx but received an ${envelopeType.name}.`
  );
}

Something important to keep in mind here is that the source account is called sourceAccount of type MuxedAccount in V1, but it is called sourceAccountEd25519 of type Uint256 in V0.

The following code handles both scenarios to pull out their string key representation:

switch (this._envelopeType) {
   case xdr.EnvelopeType.envelopeTypeTxV0():
     this._source = StrKey.encodeEd25519PublicKey(
       this.tx.sourceAccountEd25519()
     );
     break;
   default:
     this._source = StrKey.encodeMuxedAccount(
       this.tx.sourceAccount().toXDR()
     );
     break;
}

Source

Another important thing to keep in mind is that you need to do some special handling when getting the signature base for a V0 transaction.

signatureBase() {
  let tx = this.tx;
  // Backwards Compatibility: Use ENVELOPE_TYPE_TX to sign ENVELOPE_TYPE_TX_V0
  // we need a Transaction to generate the signature base
  if (this._envelopeType === xdr.EnvelopeType.envelopeTypeTxV0()) {
    tx = xdr.Transaction.fromXDR(
      Buffer.concat([
        // TransactionV0 is a transaction with the AccountID discriminant
        // stripped off, we need to put it back to build a valid transaction
        // which we can use to build a TransactionSignaturePayloadTaggedTransaction
        xdr.PublicKeyType.publicKeyTypeEd25519().toXDR(),
        tx.toXDR()
      ])
    );
  }
  const taggedTransaction = new xdr.TransactionSignaturePayloadTaggedTransaction.envelopeTypeTx(
    tx
  );
  const txSignature = new xdr.TransactionSignaturePayload({
    networkId: xdr.Hash.fromXDR(hash(this.networkPassphrase)),
    taggedTransaction
  });
  return txSignature.toXDR();
}

Source

And finally, you also need to add special handling when converting the transaction back to an xdr.TransactionEnvelope (see the implementation of toEnvelope).

For your SDK to be compatible with Protocol 12 and Protocol 13, you need to create a TransactionEnvelope with TransactionV0. If you try to submit a v1 transaction or a fee bump transaction to an instance of Stellar running Protocol 12, then it will fail.

In js-stellar-base we have a builder class which generates v0 transactions by default. You can see the implementation here. You'll also notice that we added a feature flag which allows generation of v1 transactions.

Ideally, once Protocol 13 is released, you should update your SDK to generate V1 transactions by default.

FeeBumpTransactionEnvelope

To handle the scenario when the envelope contains a FeeBumpTransactionEnvelope, let's use js-stellar-base as a reference.

You can see that we added a new class called FeeBumpTransaction, which wraps a xdr.TransactionEnvelope with a Feebump transaction https://github.com/stellar/js-stellar-base/blob/a15fc74c1f5d37e1a2a94bd610990ccea62292bb/src/fee_bump_transaction.js

In the constructor for the class above, you can see the following code:

 const envelopeType = envelope.switch();
 if (envelopeType !== xdr.EnvelopeType.envelopeTypeTxFeeBump()) {
   throw new Error(
     `Invalid TransactionEnvelope: expected an envelopeTypeTxFeeBump but received an ${envelopeType.name}.`
   );
 }

It restricts the kind of transaction envelope which can be received by this class.

You can also see that it has a getter for the innerTransaction, which returns a Transaction class that allows consumers to query data about the transaction being wrapped by the fee bump transaction. This allows you to answer questions like:

• What was the initial fee that was going to be paid for this transaction? ftx.innerTransaction.fee
• What is the hash for the innerTransaction? ftx.innerTransaction.hash
• Who are the signers for the innerTransaction? ftx.innerTransaction.signatures

Besides that, it exposes other fee bump-specific attributes like feeSource, hash, signatureBase, etc.

We also extended the builder to make it easy for users to create fee bump transactions. The helper is called buildFeeBumpTransaction.

In addition, we added a fromXDR helper function to the builder to make it easier to read a Transaction or FeeBumpTransaction. See the implementation here.

3 - Handle muxed accounts

There are two major changes around muxed accounts. The first is updating fields which expect a MuxedAccount; the second is extending Strkey to generated M... accounts.

First, you need to update the following fields — which were previously an xdr.AccountID and are now an xdr.MuxedAccount:

• PaymentOp.destination
• PathPaymentStrictReceiveOp.destination
• PathPaymentStrictSendOp.destination
• Operation.sourceAccount
• Operation.destination (for ACCOUNT_MERGE)
• Transaction.sourceAccount
• FeeBumpTransaction.feeSource

The following pull requests show you the changes in the JS library:

• #325
• #337

Second, you need to implement SEP0023, which allows you to turn a MuxedAccount into a string. A reference implementation can be found in pull request #330. See the update below about M address support.

4 - Add support for Fine-Grained Control of Authorization

CAP 18 changed the data type for the attribute authorize in AllowTrustOp. It is now a uint32 instead of a boolean. It also includes a new TrustLineFlag which is authorizedToMaintainLiabilitiesFlag with value 2.

You can see the implementation in js-stellar-base here, which still accepts booleans but converts the value to an uint32.

5 - Update Horizon response for Transaction, Balance, Operation, and Effect.

In the Horizon 1.1.0 release we added new attributes to different resources:

• The following attributes are now included in the transaction resource:
  • fee_account (the account which paid the transaction fee)
  • fee_bump_transaction (only present in Protocol 13 fee bump transactions)
  • inner_transaction (only present in Protocol 13 fee bump transactions) (#2406).
• Add support for CAP0018: Fine-Grained Control of Authorization (Protocol 13) (#2423).
  • Add is_authorized_to_maintain_liabilities to Balance.

    "balances": [
      {
        "is_authorized": true,
        "is_authorized_to_maintain_liabilities": true,
        "balance": "27.1374422",
        "limit": "922337203685.4775807",
        "buying_liabilities": "0.0000000",
        "selling_liabilities": "0.0000000",
        "last_modified_ledger": 28893780,
        "asset_type": "credit_alphanum4",
        "asset_code": "USD",
        "asset_issuer": "GBSTRUSD7IRX73RQZBL3RQUH6KS3O4NYFY3QCALDLZD77XMZOPWAVTUK"
      },
      {
        "balance": "1.5000000",
        "buying_liabilities": "0.0000000",
        "selling_liabilities": "0.0000000",
        "asset_type": "native"
      }
    ]
    

  • Add authorize_to_maintain_liabilities to AllowTrust operation.

    {
      "id": "124042211741474817",
      "paging_token": "124042211741474817",
      "transaction_successful": true,
      "source_account": "GBSTRUSD7IRX73RQZBL3RQUH6KS3O4NYFY3QCALDLZD77XMZOPWAVTUK",
      "type": "allow_trust",
      "type_i": 7,
      "created_at": "2020-03-27T03:40:10Z",
      "transaction_hash": "a77d4ee5346d55fb8026cdcdad6e4b5e0c440c96b4627e3727f4ccfa6d199e94",
      "asset_type": "credit_alphanum4",
      "asset_code": "USD",
      "asset_issuer": "GBSTRUSD7IRX73RQZBL3RQUH6KS3O4NYFY3QCALDLZD77XMZOPWAVTUK",
      "trustee": "GBSTRUSD7IRX73RQZBL3RQUH6KS3O4NYFY3QCALDLZD77XMZOPWAVTUK",
      "trustor": "GA332TXN6BX2DYKGYB7FW5BWV2JLQKERNX4T7EUJT4MHWOW2TSGC2SPM",
      "authorize": true,
      "authorize_to_maintain_liabilities": true,
    }
    

  • Add effect trustline_authorized_to_maintain_liabilities.

    {
      "id": "0124042211741474817-0000000001",
      "paging_token": "124042211741474817-1",
      "account": "GBSTRUSD7IRX73RQZBL3RQUH6KS3O4NYFY3QCALDLZD77XMZOPWAVTUK",
      "type": "trustline_authorized_to_maintain_liabilities",
      "type_i": 25,
      "created_at": "2020-03-27T03:40:10Z",
      "trustor": "GA332TXN6BX2DYKGYB7FW5BWV2JLQKERNX4T7EUJT4MHWOW2TSGC2SPM",
      "asset_type": "credit_alphanum4",
      "asset_code": "USD"
    }    
    

In the upcoming Horizon 1.2.0 release a base 64 encoding of the bytes in a transaction memo will be included in the Horizon transaction response as memo_bytes

Horizon 1.2.0 also schedule a couple of breaking changes which are required to support CAP-15.

• The type for the following attributes will be changed from int64 to string in 1.3.0:
  • fee_charged in Transaction resource.
  • max_fee in Transaction resource.

You SDK should be able to parse either a string or a number.

6 - Testing

Once you have your implementation ready, you can test it out by submitting a transaction to Horizon 1.1 or later. Remember that for now, your library should produce V0 transactions.

The Stellar Laboratory now has support for protocol 13, so you can also create V1 and fee bump transactions and test them out in the XDR viewer there.

References stellar/stellar-protocol#600.

Background

Create the API endpoints for the Asset Resource.

https://www.stellar.org/developers/horizon/reference/resources/asset.html

Endpoints

Resource Type Resource URI Template

• All Assets Collection /assets (GET)

To be to get transaction info in real time

We notice sometimes that requests hang when retrieving account information. This may be fixed not in the current version, but noting it here to double check

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.

https://www.stellar.org/developers/horizon/reference/endpoints/transactions-create.html

• create a transaction
  • figure out an API in this library that makes sense for building transactions
  • take the generated transaction and turn it into XDR
• sign transaction
• post transaction

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