Error: tx_not_supported

External question — Stellar Stack Exchange Author: Boohyung Lee Original post: https://stellar.stackexchange.com/questions/4550 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. It is developing code for sending transaction on the mainnet using stellar-sdk. A tx_not_supported error occurs during submitTransaction() . The network upgrade command( stellar-core http-command 'upgrades?mode=set&upgradetime=2018-01-31T20:00:00Z&protocolversion=15' ) was issued, but the error was not resolved. How can I solve the problem? If you need additional information, please request it through comments. Thank you. [source] // This is the end without errors. oTransaction is also. ... try { const transactionResult = await oServer.submitTransaction(oTransaction) console.log(JSON.stringify(transactionResult, null, 2)) console.log(`\nSuccess! View the transaction at: `) callback(null, transactionResult.hash) // txid } catch (err) { console.log(err.response.data.extras.result_code) // { transaction: 'tx_not_supported' } callback(err) console.log(`An error has occured.`) } [used version] stellar-core: v15.1.0 horizon: v2.0.0 captive-core: running protocol version: 15 stellar-sdk: v8.0.0 (latest) These are additional information as Justin Rice's request. Thanks. [envelopeTypeTx] Stellar Laborartory links: https://laboratory.stellar.org/#txsubmitter?input=AAAAAgAAAAA6Do45GTSz6H5%2BV99%2FMSE2und%2B0vdGVp%2Fd6FZ4l0fiAgABhqABAgADAAABHgAAAAEAAAAAAAAAAAAAAABgWTkJAAAAAAAAAAEAAAAAAAAAAAAAAAAyjg161xoXOLvvAOKmsgtLP19%2F%2B7%2Fu3nrr%2Fwlrms%2B%2FkQAAAAABMS0AAAAAAAAAAAGXR%2BICAAAAQKes5dxUhsPZejrSDhZnWahUC8apgjmmy7Cm9QB8HZZobf8jdPbow59GIlfuzcoIRQPgxsyyAd3V6yP0YT9lBQ0%3D&network=public [ERROR Response] { type: 'https: //stellar.org/horizon-errors/transaction_failed, title: 'Transaction Failed', status: 400, detail: '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: //www.stellar.org/developers/guides/concepts/list-of-operations.html', extras: { envelope_xdr: 'AAAAAgAAAAA6Do45GTSz6H5+V99/MSE2und+0vdGVp/d6FZ4l0fiAgABhqABAgADAAABHgAAAAEAAAAAAAAAAAAAAABgWTkJAAAAAAAAAAEAAAAAAAAAAAAAAAAyjg161xoXOLvvAOKmsgtLP19/+7/u3nrr/wlrms+/kQAAAAABMS0AAAAAAAAAAAGXR+ICAAAAQKes5dxUhsPZejrSDhZnWahUC8apgjmmy7Cm9QB8HZZobf8jdPbow59GIlfuzcoIRQPgxsyyAd3V6yP0YT9lBQ0=', result_codes: { transaction: 'tx_not_supported' } } } Here are the setting files. (stellar-core.cfg, stellar-captive-core-stub.toml) as you request @Bartek Nowotarski [stellar-core.cfg] LOG_FILE_PATH="/home/stellar/logs/stellar-core.log" BUCKET_DIR_PATH="/home/stellar/buckets" HTTP_PORT=8080 PUBLIC_HTTP_PORT=true PEER_PORT=11625 DATABASE="postgresql://dbname=stellar host=localhost user=stellar password=XXX" #FAILURE_SAFETY is minimum number of nodes that are allowed to fail before you no longer have quorum FAILURE_SAFETY=1 # number of ledgers to synchronize (time in seconds divided by 5) # NB: full validators should run with CATCHUP_COMPLETE=true instead CATCHUP_COMPLETE=true #CATCHUP_RECENT=60480 NETWORK_PASSPHRASE="Public Global Stellar Network ; September 2015" TARGET_PEER_CONNECTIONS=16 # Populate NODE_NAMES, KNOW_PEERS, QUORUM and HISTORY sections with information # on other validators # for example https://github.com/stellar/docs/blob/master/validators.md # or from https://dashboard.stellar.org/ NODE_NAMES=[ "GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH sdf_watcher1", "GCM6QMP3DLRPTAZW2UZPCPX2LF3SXWXKPMP3GKFZBDSF3QZGV2G5QSTK sdf_watcher2", "GABMKJM6I25XI4K7U6XWMULOUQIQ27BCTMLS6BYYSOWKTBUXVRJSXHYQ sdf_watcher3", ] KNOWN_PEERS=[ "core-live-a.stellar.org", "core-live-b.stellar.org", "core-live-c.stellar.org", ] UNSAFE_QUORUM=true [QUORUM_SET] THRESHOLD_PERCENT=51 VALIDATORS=[ "$sdf_watcher1", "$sdf_watcher2", "$sdf_watcher3" ] # Stellar.org history store [HISTORY.core_live_001] get="curl -sf http://history.stellar.org/prd/core-live/core_live_001/{0} -o {1}" [HISTORY.core_live_002] get="curl -sf http://history.stellar.org/prd/core-live/core_live_002/{0} -o {1}" [HISTORY.core_live_003] get="curl -sf http://history.stellar.org/prd/core-live/core_live_003/{0} -o {1}" [stellar-captive-core-stub.toml] [[HOME_DOMAINS]] HOME_DOMAIN="www.stellar.org" QUALITY="HIGH" [[VALIDATORS]] NAME="sdf_1" HOME_DOMAIN="www.stellar.org" PUBLIC_KEY="GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH" ADDRESS="core-live-a.stellar.org" HISTORY="curl -sf http://history.stellar.org/prd/core-live/core_live_001/{0} -o {1}" [[VALIDATORS]] NAME="sdf_2" HOME_DOMAIN="www.stellar.org" PUBLIC_KEY="GCM6QMP3DLRPTAZW2UZPCPX2LF3SXWXKPMP3GKFZBDSF3QZGV2G5QSTK" ADDRESS="core-live-b.stellar.org" HISTORY="curl -sf http://history.stellar.org/prd/core-live/core_live_002/{0} -o {1}" [[VALIDATORS]] NAME="sdf_3" HOME_DOMAIN="www.stellar.org" PUBLIC_KEY="GABMKJM6I25XI4K7U6XWMULOUQIQ27BCTMLS6BYYSOWKTBUXVRJSXHYQ" ADDRESS="core-live-c.stellar.org" HISTORY="curl -sf http://history.stellar.org/prd/core-live/core_live_003/{0} -o {1}"

External answer — Stellar Stack Exchange Author: Justin Rice Original post: https://stellar.stackexchange.com/a/4554 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I think this is what's happening: in your Captive Core config, you specified CATCHUP_COMPLETE=true . As a result, your Captive Core node is likely still catching up to the network (see Joining the Network ). While it is in that state, your node is still technically at the genesis ledger (the very beginning of the network), so its protocol version is 0. I believe you will continue to get this error for as long as your node is catching up. If you do not need to query the entire history of the network, you should use CATCHUP_RECENT instead of CATCHUP_COMPLETE . If you do want your Horizon node to ingest the full history of the network, instead of using CATCHUP_COMPLETE , you can instead use the new Horizon architecture to ingest the history from archives. Because you can parallelize archive ingestion across multiple workers, the ingestion process, which used to take weeks, can be done in ~1.5 days. For a complete guide on how to ingest from archives, see: https://github.com/stellar/go/blob/master/services/horizon/internal/docs/captive_core.md#using-captive-core-to-reingest-the-full-public-network-history