Skip to content

Instantly share code, notes, and snippets.

@2opremio
Last active September 5, 2021 04:34
Show Gist options
  • Save 2opremio/89c4775104635382d51b6f5e41cbf6d5 to your computer and use it in GitHub Desktop.
Save 2opremio/89c4775104635382d51b6f5e41cbf6d5 to your computer and use it in GitHub Desktop.
Protocol 16 support

This issue lists the changes to the Horizon API introduced by CAP-35. This CAP comprises 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 16 compliant SDK to be able to run successfully against a protocol 15 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment