Hello some Payment System recommended yor sdk for integration.
and i found error in ur method https://github.com/Soneso/stellar-php-sdk/blob/main/Soneso/StellarSDK/SEP/WebAuth/WebAuth.php
signTransaction

$signatures = array();
array_push($signatures, $envelopeXdr->getV1()->getSignatures());

we should use just
$signatures = $envelopeXdr->getV1()->getSignatures();

cuz getSignatures return array
if we use 1st variant we have incorrect subscribe transaction becos fw have wrong signature array like
[[sigen1], sign2]
when it should be
[sign1, sign2]

Soneso/StellarSDK/Transaction.php

Why does it have to be signed? Stellar Laboratory lets you import unsigned XDR envelopes so that they may be signed.

Can the signature requirement be removed or maybe it needs a new function/parameter? But the function still works with signatures, without the check. If something else in the SDK needs a signature I'm not sure this is the place to check.

/**
 * @throws Exception if transaction is not signed.
 */
public function toEnvelopeXdr(): XdrTransactionEnvelope
{
    if (count($this->getSignatures()) == 0) {
        throw new Exception("Transaction must be signed by at least one signer. Use transaction.sign().");
    }
    $xdrTransaction = $this->toXdr();
    $v1Envelope = new XdrTransactionV1Envelope($xdrTransaction, $this->getSignatures());
    $type = new XdrEnvelopeType(XdrEnvelopeType::ENVELOPE_TYPE_TX);
    $xdrEnvelope = new XdrTransactionEnvelope($type);
    $xdrEnvelope->setV1($v1Envelope);
    return $xdrEnvelope;
}

https://laboratory.stellar.org/#txsigner

If i comment out the sig check the the XDR imports just fine. But maybe this breaks something else in the SDK.

I need to generate transaction XDR so it can be submitted to third party wallet for signing and then submit the transaction to stellar.

I have not been able to find suitable example,

Anyone can help guide me though the steps?

I can get the transaction built but getting the XDR - I am not sure how.

After wallet signs the transaction how can one submit signed transaction?

Thank you for you help

I notice that guzzle errors are dumped out/printed and program terminates. So in a web application you get a blank page with a json guzzle error message like this:

{
  "type": "https://stellar.org/horizon-errors/bad_request",
  "title": "Bad Request",
  "status": 400,
  "detail": "The request you sent was invalid in some way.",
  "extras": {
    "invalid_field": "account_id",
    "reason": "Account ID must start with `G` and contain 56 alphanum characters"
  }

That's sent to the user in the case of an invalid key, IE:

//bogus invalid key
$pubkey = 'GC3CT2B55RPLE6JX2U3SOPZFGSE5A3MYFBFYAXSQCJ5BBYJX5HIBTNIX';


try {
	$account = $sdk->requestAccount($pubkey);
} catch (HorizonRequestException $e) {
	notice(  $invalid_key. ' ('.$e->getMessage().')'.EOL);
}

So, in Soneso/StellarSDK/StellarSDK.php:

public function __construct(string $uri)
{
	$this->serverUri = $uri;
	$this->httpClient = new Client([
		'base_uri' => $uri,
        'exceptions' => false,
	]);
}

I guess GuzzleHttp changed "exceptions" option to "http_errors" back in 2015. so this needs to be:

public function __construct(string $uri)
{
	$this->serverUri = $uri;
	$this->httpClient = new Client([
		'base_uri' => $uri,
        'http_errors' => false,
	]);
}

But then "this should not happen" actually happens. :)

in Soneso/StellarSDK/Responses/ResponseHandler.php:

public function handleResponse(ResponseInterface $response, string $requestType, Client $httpClient) : Response {

     $content = $response->getBody()->__toString();

     //print($content);

     // not success
     // this should normally not happen since it will be handled by gruzzle (throwing corresponding gruzzle exception)
     if (300 <= $response->getStatusCode()) {
             throw new RuntimeException($content);
     }

So it throws a 500 error and you get unhandled runtime exception in error log.

My solution was to add the status code check in Soneso/StellarSDK/Requests/RequestBuilder.php:
(so it never hits response handler)

 public function executeRequest(string $url, string $requestType, ?string $requestMethod = "GET") : Response {
        $response = null;
        try {
            $request = new Request($requestMethod, $url, RequestBuilder::HEADERS);
            $response = $this->httpClient->send($request);
        }
        catch (GuzzleException $e) {
            throw HorizonRequestException::fromOtherException($url, $requestMethod, $e, $response);
        }

        if (300 <= $response->getStatusCode()) {
                throw new HorizonRequestException('error in response: '.$response->getStatusCode());
        }

        $responseHandler = new ResponseHandler();
        try {
                return $responseHandler->handleResponse($response, $requestType, $this->httpClient);
        } catch (Exception $e) {
				throw HorizonRequestException::fromOtherException($url, $requestMethod, $e, $response);
        }
}

Now It throws HorizonRequestException since that is what is supposed to throw, according to the comments in the code.

Maybe there's a better way?

Thank you.

Soroban RPC Changes

With the introduction of stellar/soroban-tools#1152, the Soroban RPC server introduces the following changes:

sendTransaction

The response will include a new, optional field in its response schema:

• diagnosticEventsXdr: string[] - If the transaction status is "ERROR", this field may be present with an array of base64-encoded strings. Each string will decode to a raw DiagnosticEvent XDR struct containing details on why stellar-core rejected the transaction.

References

• The documentation PR: soroban-docs#700.
• An example implementation in JavaScript: stellar-sdk#905.

Upcoming Soroban RPC Change

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

• soroban-tools#1131

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

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

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

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

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

Reference implementation

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

TL;DR: Array-based passing will no longer be allowed in Soroban RPC.

Soroban RPC Changes

With the introduction of stellar/soroban-rpc#13, the Soroban RPC server changes the way it interprets the JSON-RPC spec.

Specifically, in Section 4.2, it states that parameters can be passed by position (i.e. through an array) and by name (i.e. through an object). However, endpoints that support optional parameters will not work with position-(array-)based calls. Thus, we must move exclusively to object-based calls to support optional parameters in the future.

We saw this issue introduced in Soroban RPC v20.1.0 as part of soroban-tools#1131: adding an optional parameter should be a non-breaking change, but because of array-based parameter parsing, this resulted in a breaking change in any environment using that method.

Expectations

You should remove all instances of array-based parameter passing in your low-level JSON-RPC code.

For example, RPC calls should change like this:

 {
   jsonrpc: "2.0",
   id: 1,
   method: "getTransaction",
-  params: [ "d1344aacdb36949b0164b9b97a8a4961bd9ccadcf2c3b562c93b09bc8651dad7" ]
+  params: { hash: "d1344aacdb36949b0164b9b97a8a4961bd9ccadcf2c3b562c93b09bc8651dad7" }
 }

References

• The RPC documentation outlines all of the named parameters necessary for object-based parameters.
• An example implementation in JavaScript: stellar-sdk#924.

I cant get any example to even work because there are no examples that even run auto loader with correct includes.

I know composer is wonderful but I always have problems getting it working.

Just add functional examples - that load things they need to run.

Examples listed

// create a completely new and unique pair of keys.
$keyPair = KeyPair::random();

print($keyPair->getAccountId());
// GCFXHS4GXL6BVUCXBWXGTITROWLVYXQKQLF4YH5O5JT3YZXCYPAFBJZB

print($keyPair->getSecretSeed());
// SAV76USXIJOBMEQXPANUOQM6F5LIOTLPDIDVRJBFFE2MDJXG24TAPUU7

And I get:

Fatal error: Uncaught Error: Class 'KeyPair' not found in

How am i suposed to know what to include to bring this class in?

I'm actually trying to check if an account address exist on not :

<?php

ini_set('display_errors', 0);
ini_set('display_startup_errors', 0);
error_reporting(0);

require('autoload.php');
use Soneso\StellarSDK\Asset;
use Soneso\StellarSDK\StellarSDK;
use Soneso\StellarSDK\Exceptions\HorizonRequestException;

$accountId = "GBEJWZEYDCJIKBW7PZKIJPRHD6WSPNETCEDV5UWRLDBLKXA7QT2DTLVF";
$sdk = StellarSDK::getPublicNetInstance();

try {
    $account = $sdk->requestAccount($accountId);
    echo 'Account found!';
} catch (HorizonRequestException $e) {
    echo 'Error: '. $e->getMessage();
}

?>

Address GBEJWZEYDCJIKBW7PZKIJPRHD6WSPNETCEDV5UWRLDBLKXA7QT2DTLVF did not exist, so I expect to obtain :

Error: The request you sent was invalid in some way.

Instead I obtain :

{ "type": "https://stellar.org/horizon-errors/bad_request", "title": "Bad Request", "status": 400, "detail": "The request you sent was invalid in some way.", "extras": { "invalid_field": "account_id", "reason": "Account ID must start with `G` and contain 56 alphanum characters" } } Error: The request you sent was invalid in some way.

What is wrong ?

see Soneso/stellar-ios-mac-sdk#143

I have this code:

<?php
require __DIR__ . '/vendor/autoload.php';

use Soneso\StellarSDK\StellarSDK;
use Soneso\StellarSDK\Asset;

$sdk = StellarSDK::getPublicNetInstance();

$sellingAsset = Asset::createNonNativeAsset('yXLM', 'GARDNV3Q7YGT4AKSDF25LT32YSCCW4EV22Y2TV3I2PU2MMXJTEDL5T55');
$orderBook = $sdk->orderBook()->forBuyingAsset(Asset::native())->forSellingAsset($sellingAsset)->limit(1)->execute();
$offerAmount = $orderBook->getBids()->toArray()[0]->getAmount();
$offerPrice= $orderBook->getBids()->toArray()[0]->getPrice();

When I try to send a request to order book, I encounter this error:

PHP Fatal error: Uncaught Error: Typed property Soneso\StellarSDK\Responses\OrderBook\OrderBookResponse::$bids must not be accessed before initialization in C:\Users\USER\Desktop\projects\vendor\soneso\stellar-php-sdk\Soneso\StellarSDK\Responses\OrderBook\OrderBookResponse.php:50

The problem persist on getBids() method. I also ran the test from StellarSDKTests/TradesTest.php and it passes succesfully.

I'm using:

• windows 10;
• php version 8.1.1

Trying to send a custom asset payment. If the payment fails (for example, from insufficient funds, or an inactive destination address) the script breaks and I'm unable to see the error code from Stellar, or do anything else. If the payment would have been successful, no issue.

I'm trying to submit the transaction like this:
$response = $sdk->submitTransaction($transaction);

It also breaks if I submit it like this (from an example in the examples folder):

try {
    $response = $sdk->submitTransaction($transaction);
} catch (HorizonRequestException $e) {
    print("Error submitting payment");
}

Can someone take a look, thank you.

Error logs:
[04-Aug-2023 02:51:45 UTC] PHP Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: POST **https://horizon.stellar.org/transactions?tx=AAAAAgAAAABNLuPlAK7znCjewDo%2Fcesy8k2WfT3Wzv3uEQT5sWkHcwAAAGQCCwxwAAAAGwAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAFl2UuwGhasIYsC3iEzdTylUiJxhTCg%2B2aB%2F%2FIkW8ScpAAAAAldhbHJ1c0NvaW4AAAAAAABgIf%2FzshITxLLr2hDJwtIoIQZyqN5D8brtivzcglD4fgAAAAAAAbGYAAAAAAAAAAGxaQdzAAAAQMrAldm9lhr5jNVvGXDBlu7YssiQfACcBZyA7%2F2HpvAcnAZKr84yYochZainlenDXQFrGiAsXyWTFpi1QBSbIgE%3D** resulted in a 400 Bad Request response:
{
"type": "https://stellar.org/horizon-errors/transaction_failed",
"title": "Transaction Failed",
"status": 400,
(truncated...)
in stellar/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Stack trace:
#0 stellar/vendor/guzzlehttp/guzzle/src/Middleware.php(72): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response), NULL, Array, NULL)
#1 stellar/vendor/guzzlehttp/promises/src/Promise.php(209): GuzzleHttp\Middleware::GuzzleHttp{closure}(Object(GuzzleHttp\Psr7\Response))
#2 stellar/vendor/guzzlehttp/promises/src/Promise.php(158): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp\Psr7\Response), NULL)
#3 stellar/vendor/guzzlehttp/promises/src/TaskQueue.php(52): GuzzleHttp\Promise\Promise::GuzzleHttp\Promise{closure}()
#4 stellar/vendor/guzzlehttp/promises/src/Promise.php(251): GuzzleHttp\Promise\TaskQueue->run(true)
#5 stellar/vendor/guzzlehttp/promises/src/Promise.php(227): GuzzleHttp\Promise\Promise->invokeWaitFn()
#6 stellar/vendor/guzzlehttp/promises/src/Promise.php(272): GuzzleHttp\Promise\Promise->waitIfPending()
#7 stellar/vendor/guzzlehttp/promises/src/Promise.php(229): GuzzleHttp\Promise\Promise->invokeWaitList()
#8 stellar/vendor/guzzlehttp/promises/src/Promise.php(69): GuzzleHttp\Promise\Promise->waitIfPending()
#9 stellar/vendor/guzzlehttp/guzzle/src/Client.php(124): GuzzleHttp\Promise\Promise->wait()
#10 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Requests/RequestBuilder.php(101): GuzzleHttp\Client->send(Object(GuzzleHttp\Psr7\Request))
#11 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Requests/SubmitTransactionRequestBuilder.php(33): Soneso\StellarSDK\Requests\RequestBuilder->executeRequest('/transactions?t...', 'submit_transact...', 'POST')
#12 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Requests/SubmitTransactionRequestBuilder.php(41): Soneso\StellarSDK\Requests\SubmitTransactionRequestBuilder->request('/transactions?t...')
#13 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/StellarSDK.php(277): Soneso\StellarSDK\Requests\SubmitTransactionRequestBuilder->execute()
#14 stellar/sendpayment.php(38): Soneso\StellarSDK\StellarSDK->submitTransaction(Object(Soneso\StellarSDK\Transaction))
#15 {main}

Next Soneso\StellarSDK\Exceptions\HorizonRequestException: The transaction failed when submitted to the stellar network. The extras.result_codes field on this response contains further details. Descriptions of each code can be found at: https://developers.stellar.org/api/errors/http-status-codes/horizon-specific/transaction-failed/ in stellar/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Stack trace:
#0 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Requests/RequestBuilder.php(104): Soneso\StellarSDK\Exceptions\HorizonRequestException::fromOtherException('/transactions?t...', 'POST', Object(GuzzleHttp\Exception\ClientException), NULL)
#1 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Requests/SubmitTransactionRequestBuilder.php(33): Soneso\StellarSDK\Requests\RequestBuilder->executeRequest('/transactions?t...', 'submit_transact...', 'POST')
#2 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Requests/SubmitTransactionRequestBuilder.php(41): Soneso\StellarSDK\Requests\SubmitTransactionRequestBuilder->request('/transactions?t...')
#3 stellar/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/StellarSDK.php(277): Soneso\StellarSDK\Requests\SubmitTransactionRequestBuilder->execute()

I can't work out the includes etc.

I see directories -
/vendor/soneso/stellar-php-sdk/Soneso/StellarSDK

I put a php file in /vendor/

This code just crashes error 500 -

<?php
require('autoload.php');

use Soneso\StellarSDK\Asset;
use Soneso\StellarSDK\AssetTypeCreditAlphanum4;
use Soneso\StellarSDK\ChangeTrustOperationBuilder;
use Soneso\StellarSDK\CreateAccountOperationBuilder;
use Soneso\StellarSDK\Crypto\KeyPair;
use Soneso\StellarSDK\ManageDataOperationBuilder;
use Soneso\StellarSDK\ManageSellOfferOperationBuilder;
use Soneso\StellarSDK\MuxedAccount;
use Soneso\StellarSDK\Network;
use Soneso\StellarSDK\PathPaymentStrictReceiveOperationBuilder;
use Soneso\StellarSDK\PathPaymentStrictSendOperationBuilder;
use Soneso\StellarSDK\PaymentOperationBuilder;
use Soneso\StellarSDK\Responses\Operations\CreateAccountOperationResponse;
use Soneso\StellarSDK\Responses\Operations\PaymentOperationResponse;
use Soneso\StellarSDK\StellarSDK;
use Soneso\StellarSDK\TransactionBuilder;
use Soneso\StellarSDK\Util\FriendBot;


$keyPair = KeyPair::random();
print($keyPair->getAccountId());
print($keyPair->getSecretSeed());
?>

Class Soneso\StellarSDK\SEP\Derivation\BIP39 located in ./vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/SEP/Derivation/Bip39.php does not comply with psr-4 autoloading standard. Skipping.

Hi is there a method to set the home domain when we create our own assets ?

When performing a transfer using the $sdk->submitTransaction($transaction); errors are returned to the client-side. We want to prevent these errors from being displayed to the client-side and instead display a generic error message.

Env: Laravel 9

Reproduce

$sdk = StellarSDK::getTestNetInstance();
//Build your transaction

// Leave an error on purpose (like sending non-native without a trustline)

// sign
try {
      $sdk->submitTransaction($transaction);
      return true; // return true on successful transaction submission
  } catch (\Throwable $th) {
      logger('Error in transfer method', ['error_message' => $th->getMessage()]);
      return response()->json( ['success' => false, 'message' => 'Error submitting transaction'], 400);
  } catch (\Exception $e) {
      logger('Caught exception in transfer method', ['error_message' => $e->getMessage()]);
      return  response()->json( ['success' => false, 'message' => 'Caught exception'], 400);
  }

It's logging the error but in the client side I'm getting Stellar Horizon errors

Client side

Some code on this line that's propagating error to the API request
throw HorizonRequestException::fromOtherException($url, $requestMethod, $e, $response);

👇🏽 This is definately the issue. What's happenning here?

bash print($e->getResponse()->getBody()->__toString() . PHP_EOL);

Error: Class "phpseclib3\Math\BigInteger" not found {"exception":"[object] (Error(code: 0): Class "phpseclib3\Math\BigInteger" not found at .../vendor/soneso/stellar-php-sdk/Soneso/StellarSDK/Xdr/XdrBuffer.php:67)

I have another package that requires phpseclib version ^2 but this one is not raising conflict, so if run with -W or run composer update it gets downgraded

Suggestion: Lock phpseclib/phpseclib to ^3 so that it raises conflict

It should be return strval(rtrim($bytes, "\x00")); otherwise it trims 0 too. The change could result in issues somewhere else, so it may not be the correct solution. But I did some testing, and everything looks OK.

For example:

$envelop = 'AAAAAgAAAAB+1X4E8MAjncM+MMh+9sbJsyh+VzCr8wxTFJ6hA+aNXQAAAGQAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAB+1X4E8MAjncM+MMh+9sbJsyh+VzCr8wxTFJ6hA+aNXQAAAAJBQUFBQTAwMAAAAAAAAAAAftV+BPDAI53DPjDIfvbGybMoflcwq/MMUxSeoQPmjV0AAASMJzlQAAAAAAAAAAAA';

$transaction = \Soneso\StellarSDK\Transaction::fromEnvelopeBase64XdrString($envelop);

$operations = $transaction->getOperations();

$paymentOp = $operations[0];

$asset = $paymentOp->getAsset();

var_dump($asset->getCode());

The asset code should be "AAAAA000", but we get "AAAAA".

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

Summary of Breaking Changes

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

XDR

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

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

RPC

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

I'm getting invalid timebounds when I think I'm not supposed to be getting this. Conversion bug?

Update: Never mind. I think this was fixed already and I just need a more recent version.

Protocol 21 SDK Support

Once voted in, the release of Protocol 21 will introduce following new CAPs:

• CAP-51: Smart Contract Host Functionality
• CAP-53: Separate host functions to extend the TTL for contract instance and contract code
• CAP-54: Soroban refined VM instantiation cost model
• CAP-55 : Soroban streamlined linking
• CAP-56: Soroban intra-transaction module caching

XDR changes:

XDR update issue details - stellar/stellar-xdr@1a04392

Reference Implementations:
js-sdk - stellar/js-stellar-base#738

Soroban API Changes:

Breaking Changes:

• simulateTransaction: stellar/soroban-rpc#13

Non Breaking changes:

• Add StateDiff to simulateTransaction Response: stellar/soroban-rpc#120

New optional field in SimulateTransactionResponse which indicates how the state (ledger entries) will change as a result of the transaction execution.

StateDiff       []LedgerEntryDiff            `json:"stateDiff,omitempty"`   

type LedgerEntryDiff struct {
	Before string `json:"before,omitempty"` // LedgerEntry XDR in base64
	After  string `json:"after,omitempty"`  // LedgerEntry XDR in base64
}

• Add ledger Range to getHealth RPC: stellar/soroban-rpc#133

New Ledger Range and Ledger Retention Window in getHealth Response

type HealthCheckResult struct {
	Status                string `json:"status"`
	LatestLedger          uint32 `json:"latestLedger"` // New
	OldestLedger          uint32 `json:"oldestLedger"` // New
	LedgerRetentionWindow uint32 `json:"ledgerRetentionWindow"` // New
}

Horizon API Changes:

• There are no changes to Horizon APIs

Reference Implementations

Reference implementation authored by SDF:

• JavaScript: stellar/js-stellar-sdk#935

You can follow each respective issue to its implementation PRs.

As on attached images

Hi,
Is there a way we can get the image of an asset when seeing the account balance?

Maybe I found a bug?

$txRep = TxRep::fromTransactionEnvelopeXdrBase64($data);
print "Transaction Result:  ";
print($txRep);
echo "<br><br>";


echo "<br><br>";
$envelope = TxRep::transactionEnvelopeXdrBase64FromTxRep($txRep);
print "Transaction Envelope:  ";
print_r($envelope);
echo "<br><br>";

Result of first operation is:

Transaction Result: type: ENVELOPE_TYPE_TX tx.sourceAccount: GBGZGXYWXZ65XBD4Q4UTOMIDXRZ5X5OJGNC54IQBLSPI2DDB5VGFZO2V tx.fee: 6000 tx.seqNum: 5628434382323746 tx.cond.type: PRECOND_NONE tx.memo.type: MEMO_NONE tx.operations.len: 1 tx.operations[0].sourceAccount._present: false tx.operations[0].body.type: PAYMENT tx.operations[0].body.paymentOp.destination: GD53ZDEHFQPY25NBF6NPDYEA5IWXSS5FYMLQ3AE6AIGAO75XQK7SIVNU tx.operations[0].body.paymentOp.asset: XLM tx.operations[0].body.paymentOp.amount: 100000000 tx.ext.v: 0 signatures.len: 1 signatures[0].hint: 61ed4c5c signatures[0].signature: bd33b8de6ca4354d653329e4cfd2f012a3c155c816bca8275721bd801defb868642e2cd49330e904d2df270b4a2c95359536ba81eed9775c5982e411ac9c3909

But the reverse gives an error:
Fatal error: Uncaught InvalidArgumentException: invalid tx.timeBounds in C:\xampp\htdocs\sophia_survey\vendor\soneso\stellar-php-sdk\Soneso\StellarSDK\SEP\TxRep\TxRep.php:493 Stack trace: #0 C:\xampp\htdocs\sophia_survey\vendor\soneso\stellar-php-sdk\Soneso\StellarSDK\SEP\TxRep\TxRep.php(475): Soneso\StellarSDK\SEP\TxRep\TxRep::parseTimeBounds(Array, 'tx.') #1 C:\xampp\htdocs\sophia_survey\vendor\soneso\stellar-php-sdk\Soneso\StellarSDK\SEP\TxRep\TxRep.php(256): Soneso\StellarSDK\SEP\TxRep\TxRep::parsePreconditions(Array, 'tx.') #2 C:\xampp\htdocs\sophia_survey\payment4.php(180): Soneso\StellarSDK\SEP\TxRep\TxRep::transactionEnvelopeXdrBase64FromTxRep('type: ENVELOPE_...') #3 {main} thrown in C:\xampp\htdocs\sophia_survey\vendor\soneso\stellar-php-sdk\Soneso\StellarSDK\SEP\TxRep\TxRep.php on line 493

This is on testnet.

The examples for creating a claimable balance deal with coins just created and issued:

$iomAsset = new AssetTypeCreditAlphaNum4("coin", $sourceAccountId);

or with sending a native asset instead:

$opb = new CreateClaimableBalanceOperationBuilder($claimants, Asset::native(), "11.99");

So what I can't figure out is how to create the $iomasset object here from a non-native custom asset already in a distribution wallet.

$opb = new CreateClaimableBalanceOperationBuilder($claimants, $iomAsset, "1862");
$sourceAccount = $sdk->requestAccount($sourceAccountId);
$transaction = (new TransactionBuilder($sourceAccount))
->addOperation($opb->build())->build();

Really need fast help on this. Would be super grateful.

update

I figured it out:

$iomAsset = Asset::createNonNativeAsset("lord", "GAJQTYELJNE7E6DFHWLOFAEQUJM3JDO2APLRJTKHU3WRNOTRREYNVQME");

$opb = new CreateClaimableBalanceOperationBuilder($claimants, $iomAsset, "1862");
$sourceAccount = $sdk->requestAccount($sourceAccountId);
$transaction = (new TransactionBuilder($sourceAccount))
->addOperation($opb->build())->build();

This seems to be the same case related on other Stellar libraries as this for example:
stellar/js-soroban-client#84

After some debugs on code I found that makes sense to be related to question above. I only do not understood why, if I am only replicating the same unit tests that comes with this library. Maybe the TestNet (futurenet) was upgraded after the library last release?

This is my composer.json

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

Summary of Breaking Changes

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

XDR

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

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

RPC

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

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