Community maintained Ruby SDK for Stellar
A monorepo Community maintained Ruby SDK for Stellar
This library provides a low-level interface to read, write, hash and sign the XDR structures used by Stellar Protocol.
Sources | Docs | Examples | Changelog
A client library for the Stellar Horizon API.
A meta-gem which depends on the stellar-base and stellar-horizon gems.
It provides a convenient way to add full Stellar SDK to your project.
Sources | Docs | Examples | Changelog
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "github-actions[bot]")
Hey @ramontayag, we actually pushed back the renames mentioned in #56 to 0.19.0, but wanted to send this your way regarding the other deprecations present — feel free to close if you're already good to go.
Horizon 0.18.0 has been released, which continues additional work for a better integration with Stellar Protocol 11. This release contains breaking changes from 0.17.*, including a requirement to use Postgres 9.5+, along with various changes, including deprecations, that further support the protocol changes presented in CAP-0005 and CAP-0006.
You can find the official release on Github; below are the release notes.
This issue has been filed as a reminder for compatibility — if your SDK is already compatible, feel free to just respond on the thread and close it out. Thank you, and let me know if you have any questions!
paging_token field from /accounts/{id} endpoint./operation_fee_stats endpoint. Please use /fee_stats.fee_paid field on Transaction resource has been deprecated and will be removed in 0.19.0. Two new fields have been added: max_fee that defines the maximum fee the source account is willing to pay and fee_charged that defines the fee that was actually paid for a transaction. See CAP-0005 for more information.manage_offer and create_passive_offer. The names will be changed to: manage_sell_offer and create_passive_sell_offer in 0.19.0.max-db-connections config parameter is set, it has a priority over the the new params. Run horizon help for more information.
horizon-db-max-open-connectionshorizon-db-max-idle-connectionscore-db-max-open-connectionscore-db-max-idle-connectionsfee_paid value in Transaction resource ( #1358 ).int64: value out of range errors in trade aggregations ( #1319 ).horizon db reingest range command.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.
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.
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.
The following changes have been made to the SEP-10 protocol:
home_domain value in a SEP-10 challenge's first Manage Data operationSIGNING_KEY
SEP-10 2.1.0 Changes
Go SDK SEP-10 2.1.0 Support
JavaScript SDK SEP-10 2.1.0 Support
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.
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 thatCreateAccountOpis invalid ifstartingBalance = 0will 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.
Protocol V11 of Stellar adds a new manage_buy_offer operation. Also names of manage_offer and create_passive_offer have been changed to manage_sell_offer and create_passive_sell_offer.
References:
src/xdr (realistically any file that ends with a .x extension).Let me know if you have any questions!
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.
My two picks are:
--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.You can see the full changelog in the release notes https://github.com/stellar/go/releases/tag/horizon-v1.5.0
As of right now, the contract specified by Stellar::Client#create_account requires an integer as the starting_balance. This needs to expect Stellar::Amount instead, making possible to use create_account and send_payment interchangeably, after verifying that the account doesn't/does exist.
SEP 10 describes a specific form for the "challenge" transaction used for authentication. Providing a helper at the SDK level makes sense to save users from reimplementing the spec.
When creating a Stellar::Client object, we receive an uninitialised constant error, I have been unable to find any definition of the Stellar::Currency class in either the stellar-base or stellar-sdk.
In this specific case we are expecting a Stellar::Currency.native() method.
require 'stellar-sdk'
client = Stellar::Client.localhost()/var/lib/gems/2.3.0/gems/stellar-sdk-0.1.1/lib/stellar/amount.rb:8:in `<class:Amount>': uninitialized constant Stellar::Amount::Currency (NameError)
from /var/lib/gems/2.3.0/gems/stellar-sdk-0.1.1/lib/stellar/amount.rb:2:in `<module:Stellar>'
from /var/lib/gems/2.3.0/gems/stellar-sdk-0.1.1/lib/stellar/amount.rb:1:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
from /var/lib/gems/2.3.0/gems/backports-3.6.8/lib/backports/std_lib.rb:9:in `require_with_backports'
from /var/lib/gems/2.3.0/gems/stellar-sdk-0.1.1/lib/stellar/client.rb:59:in `<class:Client>'
from /var/lib/gems/2.3.0/gems/stellar-sdk-0.1.1/lib/stellar/client.rb:4:in `<module:Stellar>'
from /var/lib/gems/2.3.0/gems/stellar-sdk-0.1.1/lib/stellar/client.rb:3:in `<top (required)>'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
from /var/lib/gems/2.3.0/gems/backports-3.6.8/lib/backports/std_lib.rb:9:in `require_with_backports'
from create_account.rb:24:in `<main>'
Is this genuine or am I missing something obvious?
Add more the README so new users see how to properly use the SDK before reverting to reading the source code and using deprecated methods.
We recently deprecated methods on Transaction that construct single-operation transactions in favor of TransactionBuilder, see the PR.
Client has methods that call these deprecated functions and is not yet deprecated itself:
account_mergecreate_accountsend_paymentchange_trustImplement 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.
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.
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.
Are there any plans to make a release soon? I need to pull in the changes from #40 and am hoping not to be on a forked version for too long, so I thought I'd ask.
For improved efficiency, I need to get transactions for an account by passing the cursor parameter, which is not currently implemented in the SDK.
Here's an example request: https://horizon-testnet.stellar.org/accounts/GBFNS3CR7W45U473RFUEA7A2RGLCVGT6LKN4V6AFWD77AA5JKY6P2IIN/transactions?cursor=37933069553897472
See the cap15-support branch on this repository for a WIP implementation of the changes described below.
Changes needed:
TransactionEnvelope to TransactionV1Envelope or find a backwards-compatible fix.
TransactionEnvelope from a struct to a union and renamed the original definition TransactionV1Envelope. Since this class is autogenerated, the ruby class and its attributes will also be changed. We should try to find a fix for this, otherwise the code of anyone who works with these objects will break when they upgrade to the version that includes CAP-15 support.FeeBumpTransaction in lib/stellar
TransactionFeeBumpTransactionEnvelope in lib/stellar
TransactionV1EnvelopeThe following changes were recently merged to SEP-10:
homeDomain FQDN instead of the anchorName stringSIGNING_KEY attribute in the stellar.toml of the service implementing SEP-10 is requiredSIGNING_KEY keypair was used to sign the challenge transactionEach 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.
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:
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.
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.
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.
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;
}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();
}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.
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:
ftx.innerTransaction.feeftx.innerTransaction.hashftx.innerTransaction.signaturesBesides 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.
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.destinationPathPaymentStrictReceiveOp.destinationPathPaymentStrictSendOp.destinationOperation.sourceAccountOperation.destination (for ACCOUNT_MERGE)Transaction.sourceAccountFeeBumpTransaction.feeSourceThe following pull requests show you the changes in the JS library:
Second, you need to implement SEP0023, which allows you to turn a See the update below about M address support.MuxedAccount into a string. A reference implementation can be found in pull request #330.
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.
In the Horizon 1.1.0 release we added new attributes to different resources:
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).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"
}
]
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,
}
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.
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.
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.
As discussed in astroband/ruby-stellar-base#58, there is support for merging the base repo into this one as long as this project outputs a clear error or warning for when ruby-stellar-base is still installed.
The fee_paid field in the Horizon transaction response will be removed when Horizon 0.25 is released. The fee_paid field has been replaced by max_fee, which defines the maximum fee the source account is willing to pay, and fee_charged, which defines the fee that was actually paid for a transaction. See CAP-0005 for more information.
Passing empty string (or space) as a value for ManageData operation currently results in nil value, which invokes "delete data entry" behaviour.
It should be possible to create a data entry with empty value.
Here's a failing test case, which runs a decode/encode cycle on a transaction containing manage data operation with empty value (created via JS SDK).
context 'when data value present, but empty' do
let(:xdr) { 'AAAAAgAAAAA4ANW/vvpV1b8ApF7yOll42QB15CdfV82FnEoMRNPNqQAAAZAAERvWAAAACAAAAAEAAAAAAAAAAAAAAABgq8IZAAAAAAAAAAQAAAAAAAAACgAAAEAwMGV5SjBlWEFpT2lKS1YxUWlMQ0poYkdjaU9pSklVekkxTmlKOS5leUpwYzNNaU9pSm9kSFJ3Y3pvdkwzUmxjAAAAAQAAAEAzUmhibU5vYjNJdWMzUmxiR3hoY2k1dmNtY3ZZWFYwYUNJc0luTjFZaUk2SWtkQk5FRkNWazQzV0RNMVJreFdUAAAAAAAAAAoAAABAMDFqZEJRMU5HTlRSU01reEdORTVUUVVSV05GRlVWalpXTms1UlYwOUZWVVJEUlRKUVJ6SlRTVU5OSWl3aWFXRgAAAAEAAABAMElqb3hOakl4T0RZME1qYzNMakU1T0RJeU9UZ3NJbVY0Y0NJNk1UWXlNVGsxTURZM055NHhPVGd5TWprNExDSgAAAAAAAAAKAAAAQDAycWRHa2lPaUprWXpkbE5EUXdOV1EzT1Rkak1qVTVNall4T1dFMU5tRXhOMk13T0RrNVl6QXlORFpqT1dVeVkAAAABAAAAQFdWa05tUXpaV1prTkRWbU1tSXpPVFEyTnpCbVl6STFJaXdpWTJ4cFpXNTBYMlJ2YldGcGJpSTZiblZzYkgwLmQAAAAAAAAACgAAACwwM1Y2LXk4TnlPb255Ql9CQjNyU0JtRWU4clhXSWFrQjQ1U0Jmc1l5UUVtNAAAAAEAAAAAAAAAAAAAAAFE082pAAAAQCKDqTaAduIsqqHjjOk0gE2DavgPk4l0pbu+b2AVSzTBcB2grwhAAQ0QKddF5Dqao3tMWGwyaU+aUOV4wNNL1Q4=' }
it 'should not change after decode/encode cycle' do
expect(Stellar::TransactionEnvelope.from_xdr(xdr, :base64).to_xdr(:base64)).to eq(xdr)
end
endUsers are currently required to set Stellar.default_network in order to submit transactions to mainnet. If users have clients for multiple different networks, they have to reset default_network before every submission.
This requirement is missed by many newcomers and can be confusing to even experienced users when they explicitly declare a client for mainnet but still have to set this attribute on the top-level module.
This design also differs from most of the SDKs (Go, Python, JavaScript, etc.). Instead, these SDK's accept the network passphrase as a parameter to the function that need it. See the JS library's TransactionBuilder, for example.
We should change the ruby implementation to accept these same parameters while maintaining backwards compatibility. This likely means the network will have to come in the form of a keyword argument. If omitted, the SDK can still use Stellar.default_network, but downstream errors due to not setting this attribute should be replaced with a suggestion to pass the network passphrase to the function or object constructor.
irb> require 'stellar-sdk'
irb> client = Stellar::Client.default_testnet
irb> pubkey = "GAJQ4J2EDDVCBIQIJ5XA2S4UJQKXCHFNOR67AOVQ2YQAVZ42LDLTJN4A"
irb> account = Stellar::Account.from_address(pubkey)
irb> ac_info = client.account_info(account)
This returns a Hyperclient::Link instance. Calling _get on this throws a 404 error (even though the account exists).
Faraday::ResourceNotFound (the server responded with status 404)
Looks like a case of variable name mismatch:
irb> ac_info.inspect
=> #<Hyperclient::Link(account) {"href"=>"https://horizon-testnet.stellar.org/accounts/{account_id}", "templated"=>true}>
irb> ac_info.instance_variable_get("@uri_variables")
=> {:address=>"GAJQ4J2EDDVCBIQIJ5XA2S4UJQKXCHFNOR67AOVQ2YQAVZ42LDLTJN4A"}
Notice the difference. The href is expecting a variable called account_id but uri_variables hash contains address.
The Stellar::Client class is missing an overarching design philosophy. Only about a third of the operations Horizon supports are implemented in the client, it has some utility functions for calling friendbot or building a SEP10 challenge transaction, and it has a method returning a TransactionPage object for calling the "next" page of results for a /transactions call.
@tomerweller feels as though these helper methods for constructing and POSTing transactions to Horizon don't add much value considering their maintenance cost. I think I agree, considering that they're essentially wrappers around Stellar::Transaction.
The SEP10 helper methods are also being moved to a new SEP10 module (see #69).
So, I think we should step back and consider the purpose of this class. From what I can see, its mainly for containing the @horizon Hyperclient object, which users can use directly to make calls to Horizon.
We should decide if Stellar::Client should be a thin wrapper around the @horizon object, or if we should add methods to the class for users to utilize instead of using @horizon directly. Right now, its a mix of both.
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.
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
None
Claimable Balance
v1). For now there's only a possible flag (CLAIMABLE_BALANCE_ENABLED_FLAG)Trustline
AUTH_CLAWBACK_ENABLED_FLAG)None
None
clawback with the following fields:
asset_typeasset_codeasset_issuerfrom - account from which the asset is clawed backamount - asset amount clawed backclawback_claimable_balance, with the following fields:
balance_id - claimable balance identifer of the claimable balance to be clawed backset_trust_line_flags, with the following fields:
asset_typeasset_codeasset_issuertrustor - account whose trustline is affected by this operationAUTH_CLAWBACK_ENABLED_FLAG flag)
set_flags - array containing the integer (XDR) representation of the flags to enableset_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 disableclear_flags_s - array containing the textual representation of the flags in clear_flags (possible values are: authorized, authorized_to_maintain_liabilites and clawback_enable)trustline_flags_updated, with the following fields:
asset_typeasset_codeasset_issuertrustor - account whose trustline the effect refers toauthorized_flag - true to indicate the flag is set, field ommited if not setauthorized_to_maintain_liabilites - true to indicate the flag is set, field ommited if not setclawback_enabled_flag - true to indicate that the flag is set, field ommitted if not setclaimable_balance_clawed_back, with the following fields:
balance_id - claimable balance identifer of the claimable balance clawed backOperation 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.
begin
client = Stellar::Client.default_testnet()
client.create_account({
funder: Stellar::Account.random(),
account: Stellar::Account.random(),
starting_balance: 10_000_000 * Stellar::ONE,
sequence: 1,
})
puts friendbot.address
rescue Exception => e
puts "Error: #{e.message}"
end
Give us :
`Error: the server responded with status 400`
Any advice? Regards
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).
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.
The upcoming stellar-core protocol 12 release will add support for CAP 24 ("Make PathPayment Symmetrical").
To support this change, the following steps are necessary:
PathPayment operation should be deprecated (it will be renamed to PathPaymentStrictReceive in protocol 12, with behavior unchanged). Consider adding the new operation name immediately as an alias during the transition period.PathPaymentStrictSend will be available and should be provided. This is expected to happen around the end of October, 2019.path_payment operation name in responses until Horizon 0.24. Both types of path_payment operation will be returned with the existing name. In Horizon release 0.24 (targeted for ~10 weeks from now, Horizon will change, and begin to return path_payment_strict_receive and path_payment_strict_send in the type field of responses that refer to operations or payments. You should update client code if necessary (e.g. for validation) and note this for users.For further information, see the following issues in the SDF Go monorepo:
As described in stellar/go#725, it would be really helpful if this SDK sent two simple headers with each request, identifying the SDK and version:
two headers are sent: client name (
X-Client-Name) and version (X-Client-Version)
This will help maintainers of public Horizon instances understand where their traffic is coming from, and allow them to assess the impact of upgrading their Horizon version (for example they might delay upgrading to a version with breaking changes not handled by a client SDK with significant traffic to the server).
Hi team,
I have a simple user creation.
On my model and registration controller i have:
def set_keys
account = Stellar::Account.random()
self.secret_key = account.keypair.seed
self.address_key = account.keypair.address
end
My data is:
secret_key = "SARARAK4BVGVOGI7YANOGCFDRMUYWEAB3KTCWIDRNHAN67ZEUVOOQ5KL"
address_key = "GAFHDGIVYMJLGRP4OMLYNB72KHLNKMUC5UPXBV4AJDUEOUM2TCJZDK53"
When i tried to funding the account with:
begin
account = Stellar::Account.from_seed(current_provider.secret_key)
client = Stellar::Client.default_testnet()
response = client.friendbot(account)
puts response
rescue Exception => error
puts error.message
end
I get this error:
NotImplementedError
Am i missing something or any advice?
If i tried with testnet with:
begin
client = Stellar::Client.default_testnet
friendbot = Stellar::Account.from_seed(current_provider.secret_key)
client.create_account({
funder: Stellar::Account.master,
account: friendbot,
starting_balance: 10_000_000 * Stellar::ONE,
sequence: 1,
})
puts friendbot.address
rescue Exception => error
puts error.message
end
i get this error:
the server responded with status 400
Hi everyone, i'm working with a simple app, i have this code on my user creation:
account = Stellar::Account.random
self.seed_key = account.keypair.seed
self.address_key = account.keypair.address
client = Stellar::Client.default_testnet()
friendbot = Stellar::Account.from_seed(account.keypair.seed)
client.create_account({
funder: Stellar::Account.master,
account: friendbot,
starting_balance: 10_000_000 * Stellar::ONE,
sequence: 1,
})
But when the code runs, this error shows:
Faraday::ClientError (the server responded with status 400):
Am i missing something?
Thanks in advance
Once #78 is merged we should update the examples to use submit_transaction. The checks it performs aren't valuable if nobody is using it.
Currently, the "Get lumens" feature on stellar.org/galaxy is borked. The tool is generating address and seed appropriately (it seems) but can't issue lumens.
Hi, i new with Stellar on Ruby i know how to use it on python and Node i wanna create an account but need to save the public and secret key on database.
This function give me "GAD4FCA5LB52ANMT7IOOLGSD6UDVE6IQBJKVOYIZCCEMAWSYK2LEM5NT" that i supouse is the public key:
account = Stellar::Account.random()
But how i get the secret?
Regards!
I see nothing posted since last year ? better use JSON rpc ?
A change has been released in SEP-10 Web Authentication v1.3.0 that adds support for:
SEP-10 v1.3.0 Change: stellar/stellar-protocol@ea0d7ed
The new functionality requires changes to any SDK implementing challenge verification.
The Stellar Go SDK is the first SDK we've implemented this new functionality and it can be used as a reference. It has implemented the following changes and similar changes may be required in this SDK:
VerifyChallengeTx).ReadChallengeTx)VerifyChallengeTxThreshold)VerifyChallengeTxSigners)Go SDK Change: stellar/go@8ff0848
An example of a SEP-10 server using the v1.3.0 verification process is implemented here:
https://github.com/stellar/go/tree/master/exp/services/webauth
If anyone has any questions feel free to join us in #dev-discussion in stellar.public Keybase.
See astroband/ruby-stellar-base#30
If you don't do Stellar.default_network = Stellar::Networks::PUBLIC, you will get a tx_bad_auth error.
Maybe this library should set default_network in the Stellar::Client.default and Stellar::Client.default_testnet methods
Only reason I could see for not doing this, is if you are using the testnet, but want to construct a client for the publicnet but not use it immediately.
Add support for SEP 29. This is important to provide a simple way to protect users from forgetting memos when submitting payments to exchanges.
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.
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#516Go SDK: stellar/go#2396With Horizon v0.18.0, the following breaking changes will occur:
manage_offer endpoint will be renamed to manage_sell_offercreate_passive_offer endpoint will be renamed to create_passive_sell_offer.We suggest for all Stellar SDK maintainers to offer compatibility between v.0.17.X type names as well as the new names in v.0.18.0 in order to make the transition process from v0.17.X to v0.18.0 to go smoother.
Let me know if you have any questions!
In Horizon release 0.17.0 (released 26 Feb 2019), several breaking changes were made (changelog), changing or removing fields that had previously been marked as deprecated.
Breaking changes
Fields removed in this version: Root > protocol_version, use current_protocol_version and core_supported_protocol_version. Ledger > transaction_count, use successful_transaction_count and failed_transaction_count. Signer > public_key, use key. This Horizon version no longer supports Core <10.0.0. Horizon can still ingest version <10 ledgers. Error event name during streaming changed to error to follow W3C specification.
Here is the relevant Horizon commit, showing the fields that were changed: stellar/go@575707e
This is an urgent issue! Any code using this SDK to access a Horizon 0.17.0 server (which includes the SDF public horizon instance at https://horizon.stellar.org/) will be broken until the SDK is updated to match the new response fields.
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
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).
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.
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()).
While running gem build ruby-stellar-base.gemspec we got the following warnings, we should fix them:
WARNING: license value 'Apache 2.0' is invalid. Use a license identifier from
http://spdx.org/licenses or 'Nonstandard' for a nonstandard license.
Did you mean 'Apache-2.0'?
WARNING: open-ended dependency on digest-crc (>= 0) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on base32 (>= 0) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on rbnacl (>= 6.0) is not recommended
if rbnacl is semantically versioned, use:
add_runtime_dependency 'rbnacl', '~> 6.0'
WARNING: open-ended dependency on activesupport (>= 5.0.0) is not recommended
if activesupport is semantically versioned, use:
add_runtime_dependency 'activesupport', '~> 5.0', '>= 5.0.0'
WARNING: open-ended dependency on xdrgen (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on guard-rspec (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on simplecov (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on octokit (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on netrc (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on yard (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
I've installed stellar-sdk and libsodium on Ubuntu 14.04.5 LTS:
$ gem list | grep stellar
stellar-base (0.17.0)
stellar-sdk (0.5.0)
$ sudo apt list --installed | grep sodium
WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.
libsodium-dev/trusty,now 1.0.3-1chl1-trusty1 amd64 [installed]
libsodium13/trusty,now 1.0.3-1chl1-trusty1 amd64 [installed,automatic]
But I have a run-time error when I require staller-sdk on irb:
$ irb
irb(main):001:0> require 'staller-sdk'
RuntimeError: rbnacl-libsodium is not supported by rbnacl 6.0+. Please remove it as a dependency and install libsodium using your system package manager. See https://github.com/crypto-rb/rbnacl#installation
What shall I do?
Stellar::Client.default.create_account signs things with testnet
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 justKEY_TYPE_MUXED_ED2551), two new fields are
added to the JSON.
Base field name +
_muxedis the strkey of the multiplexed account.Base field name +
_muxed_idis 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.
"account_muxed", "account_muxed_id", "fee_account_muxed" and "fee_account_muxed_id".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"."account_muxed", "account_muxed_id". Additional fields depending on the effect type:
"trade" effect: "seller_muxed" and "seller_muxed_id".You can use the Go SDK implementation as a reference:
Making a request to the Stellar::Operation.manage_buy_offer prompts an error: Unknown attribute 'amount' for Stellar::ManageBuyOfferOp
The ManageBuyOfferOp struct expects buyAmount
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:
In what follows, "canonical form" means code:address or native (for the XLM asset).
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).sponsor field (account ID, can be null).num_sponsoring field - number of reserves sponsored by this account,num_sponsored field - number of reserves sponsored for this account.sponsor field (account ID) in Account > Balance object (only for non-native assets, can be null).sponsor field (account ID) in Account > Signers object (can be null).sponsor field (account ID) in Account's Data object (can be null).sponsor field (account ID) in Offer object (can be null)./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./accounts can now by filtered by sponsor (new GET param)./offers can now by filtered by sponsor (new GET param).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.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 fieldpredicate 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
RevokeSponsorshipOpThe 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 .
Stellar::Memo.new seems to validate that the memo provided is the right data type:
[36] pry(main)> Stellar::Memo.new(:memo_text, {foo: 'bar'})
XDR::InvalidValueError: XDR::InvalidValueError
from .../gems/xdr-3.0.0/lib/xdr/union.rb:86:in `set'But it does not look at the value itself to validate length:
[37] pry(main)> Stellar::Memo.new(:memo_text, 'x' * 10000)
=> #<Stellar::Memo:0x007fdc5f3a7198
@arm=:text,
@switch=#<Stellar::MemoType:0x007fdc5d80e800 @name="memo_text", @value=1>,
.....From my perspective it'd be great if the contract were that if Stellar::Memo.new returns a value, that value will be able to be serialized into XDR successfully.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.