Giters

Synesso / scala-stellar-sdk

Scala SDK for the Stellar network

Home Page:https://synesso.github.io/scala-stellar-sdk

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Protocol 16 support

2opremio opened this issue · comments

commented

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.

commented

Update: CAP35 will now be included in Protocol 17

Version 16 of the protocol was used to resolve an issue in the network.
(If interested, there is a blogpost explaining the details).

As a result, CAP35 will be included in Protocol 17. In other words, all the references to Protocol 16 above, now apply to Protocol 17.

commented

Done in v0.20.0