pool = {
...
    liquidity_asset_name': liquidity_asset['params']['name']
...

A workaround for us is just a simple liquidity_asset['params'].get('name'), but you'd probably want a solution/name that includes the other ASA in the pool.

Running the following on mainnet:

ALGO = client.fetch_asset(0)
OPUL = client.fetch_asset(287867876)
pool = client.fetch_pool(OPUL, ALGO)
quote = pool.fetch_fixed_input_swap_quote(ALGO(2500), slippage=0.01)

returns, for example, 2955 as quote.

In reality, this is actually 0.2955, so the quote is actually is off by exactly 10000 for some reason.

Minimum code to reproduce:

from tinyman.v1.client import TinymanClient
from algosdk.v2client.algod import AlgodClient

algod = AlgodClient('', 'https://api.algoexplorer.io', headers={'User-Agent': 'algosdk'})

# V1 client
client_v1 = TinymanClient(algod_client=algod, validator_app_id=350338509)
# V1.1 client
client_v2 = TinymanClient(algod_client=algod, validator_app_id=552635992)

# Get two assets
YLDY = client_v1.fetch_asset(226701642)
ALGO = client_v1.fetch_asset(0)

# Find pool (which definitely still exists)
# Actual target address is 
# Y74RXNAUAZT2U5PD57Y22NVU6UPW5WNLRLHA763EE5IJSLSJXRAX6YY4OE
pool = client_v1.fetch_pool(YLDY, ALGO)
pool.address # FNWKQUJCBFEW3OIUFAV5WD5WF6YZ52DKCVVCVTW5G53TOY5RS4AX57SFXU

# Actual target address is 
# KX6S647W6BEN6XHEJVMXK3UYLVNGT2Q6PHQSF5AA2JSSDFSOX7R4MESXRY
pool2 = client_v2.fetch_pool(YLDY, ALGO)
pool2.address # KX6S647W6BEN6XHEJVMXK3UYLVNGT2Q6PHQSF5AA2JSSDFSOX7R4MESXRY

I have been trying to keep an updated price of an ASA. It was originally checking at 10 second intervals, I have also tried it at 30 second intervals. It can run happily for anywhere between 2 and 8 hrs, but then I get the 429 error and limit exceeded message. Once banned / blocked, there doesn't seem to be any clue as to when I will be unblocked.

The error comes directly from calling: pool = client.fetch_pool then quote = pool.fetch_fixed_input_swap_quote I'm using the standard example code for getting the swap quotes

1. What are the API limits?
2. Is there any way to catch this before it triggers the block / ban?
3. Is this something tinyman-py-sdk should handle, or is it an algod issue?

I haven't been able to find anything about the API rate limit online

I have a loop in which I am checking some conditions. Once these conditions verified, I am submitting an order.

Very few times where the submit function is called without an error but most of the time I have the following exception.

result = client.submit(transaction_group1, wait=True) File "D:\Programs\lib\site-packages\tinyman\v1\client.py", line 34, in submit raise Exception(json.loads(e.args[0])['message']) from None File "D:\Programs\lib\json_init_.py", line 346, in loads return _default_decoder.decode(s) File "D:\Programs\lib\json\decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "D:\Programs\lib\json\decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Any idea about the root cause of this non deterministic behavior resulting to this exception? Many Thanks

I have added an opt in transaction for assets in the client, which makes it simpler to resolve the error raised in https://github.com/tinymanorg/tinyman-py-sdk/issues/8

I get the price of a token via sdk via the example code For example the price of goETH But there is a problem, the price received via sdk is very different from the price inside the site (I tested it again today, the price difference was about $ 40!)

It could happen that the function wait_for_confirmation(client, txid) is running/waiting undefinitely. This happens some times for a reason that I cannot explain.

Do you know in which case this situation can happen?

A suggestion could be to define the wait_for_confirmation and submit functions with an additional timeout parameter, for example:

def wait_for_confirmation(client, txid, timeout)

and/or

def submit(transaction_group, wait, timeout): ---> when wait = True, a timeout could be given.

thinking i may have to use algod for this? i want to keep purchasing an asset until I spend all ALGO, I don't want to purchase it all at once because slippage will be too high

I am encountering the following issue when attempting to exchange two coins on tinyman using testnet.

Following the steps inhttps://github.com/tinymanorg/tinyman-py-sdk/blob/main/examples/swapping1.py, which work for Mainnet without problem, the code crashes with an AlgodHTTPError. Here is a minimal example:

from tinyman.v1.client import TinymanTestnetClient
client=TinymanTestnetClient(user_address=address)
assert(client.is_opted_in())
algo=client.fetch_asset(0)
usdc=client.fetch_asset(10458941)
pool = client.fetch_pool(usdc, algo)
quote = pool.fetch_fixed_input_swap_quote(algo(1_000_000), slippage=0.01)
transaction_group = pool.prepare_swap_transactions_from_quote(quote)
transaction_group.sign_with_private_key(address, private_key)
result = client.submit(transaction_group, wait=True)

which fails with the following error

---------------------------------------------------------------------------
JSONDecodeError                           Traceback (most recent call last)
<ipython-input-10-82e8ae16ad39> in <module>
      5 transaction_group = pool.prepare_swap_transactions_from_quote(quote)
      6 transaction_group.sign_with_private_key(address, private_key)
----> 7 result = client.submit(transaction_group, wait=True)

~/.local/lib/python3.9/site-packages/tinyman/v1/client.py in submit(self, transaction_group, wait)
     32             txid = self.algod.send_transactions(transaction_group.signed_transactions)
     33         except AlgodHTTPError as e:
---> 34             raise Exception(json.loads(e.args[0])['message']) from None
     35         if wait:
     36             return wait_for_confirmation(self.algod, txid)

/usr/lib/python3.9/json/__init__.py in loads(s, cls, object_hook, parse_float, parse_int, parse_constant, object_pairs_hook, **kw)
    344             parse_int is None and parse_float is None and
    345             parse_constant is None and object_pairs_hook is None and not kw):
--> 346         return _default_decoder.decode(s)
    347     if cls is None:
    348         cls = JSONDecoder

/usr/lib/python3.9/json/decoder.py in decode(self, s, _w)
    335 
    336         """
--> 337         obj, end = self.raw_decode(s, idx=_w(s, 0).end())
    338         end = _w(s, end).end()
    339         if end != len(s):

/usr/lib/python3.9/json/decoder.py in raw_decode(self, s, idx)
    353             obj, end = self.scan_once(s, idx)
    354         except StopIteration as err:
--> 355             raise JSONDecodeError("Expecting value", s, err.value) from None
    356         return obj, end

JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Is there something that needs to be set up differently for a swap on testnet, or perhaps something that changed on the algosdk library which is causing this issue?

Getting err mentioned in the title on submitting the swap group transaction

Right now i am using node v 14.0 and algosdk version 1.17.0

Steps to reproduce

so here is what we are doing we are trying to swap using tinyman sdk we have a backend i send him params req to do swapping there he creates 4 transaction ( a group transaction) 2 of which are meant to be signed by tinyman sdk and two are meant to be signed by the frontend aka the person who is trying to do the swapping ... so what backend does is he signs the txn that needs to be signed by the backend and send me the all 4 txns ... i sign the remaining 2 txns and create a array and submit those ... while submitting that txn i get the msgpack error at pos: 294

here is the code that i am performing on the frontend

                             const decoded_txn1 = algosdk.decodeSignedTransaction(
				Buffer.from(res.data.signed_txn.stxn1, "base64")
			).lsig?.l;
			console.log(
				"the decoded txn is :",
				algosdk.decodeSignedTransaction(
					Buffer.from(res.data.signed_txn.stxn1, "base64")
				)
			);
			const decoded_txn2 = algosdk.decodeSignedTransaction(
				Buffer.from(res.data.signed_txn.stxn2, "base64")
			).lsig?.l;
			console.log(
				"the decoded txn is :",
				algosdk.decodeSignedTransaction(
					Buffer.from(res.data.signed_txn.stxn2, "base64")
				)
			);
			// const txnId1 = await myAlgoConnect.signTransaction(res.data[0].txn);
			const signedTxns: any = await myAlgoConnect.signTransaction(
				[res.data.unsigned_txn.txn1, res.data.unsigned_txn.txn2].map(
					(txn: any) => txn
				)
			);
			console.log("the signed txn is :", signedTxns);
			const signed = [];
			signed.push(signedTxns[0].blob);
			signed.push(decoded_txn1);
			signed.push(signedTxns[1].blob);
			signed.push(decoded_txn2);

			console.log("the signe array is :", signed);

			let tx = await client.sendRawTransaction(signed).do();
			console.log("Transaction : " + tx.txId);
			let confirmedTxn = await algosdk.waitForConfirmation(
				client,
				tx.txId,
				4
			);
			console.log("the confirmed txn is :", confirmedTxn);
		}

-the res.data.signed_txn are the txn that are already signed by the backend -the res.data.unsigned_txn are the txn that needs to be signed by the frontend

the data that i am getting from backend is { "signed_txn": { "stxn1": "gqRsc2lngaFsxQNcBCAIAQAAva7+BAMEBQYlJA1EMQkyAxJEMRUyAxJEMSAyAxJEMgQiDUQzAQAxABJEMwEQIQcSRDMBGIGs194dEkQzARkiEjMBGyEEEhA3ARoAgAlib290c3RyYXASEEAAXDMBGSMSRDMBG4ECEjcBGgCABHN3YXASEEACOzMBGyISRDcBGgCABG1pbnQSQAE7NwEaAIAEYnVybhJAAZg3ARoAgAZyZWRlZW0SQAJbNwEaAIAEZmVlcxJAAnkAIQYhBSQjEk0yBBJENwEaARclEjcBGgIXJBIQRDMCADEAEkQzAhAhBBJEMwIhIxJEMwIiIxwSRDMCIyEHEkQzAiQjEkQzAiWACFRNUE9PTDExEkQzAiZRAA+AD1RpbnltYW5Qb29sMS4xIBJEMwIngBNodHRwczovL3RpbnltYW4ub3JnEkQzAikyAxJEMwIqMgMSRDMCKzIDEkQzAiwyAxJEMwMAMQASRDMDECEFEkQzAxElEkQzAxQxABJEMwMSIxJEJCMTQAAQMwEBMwIBCDMDAQg1AUIBsTMEADEAEkQzBBAhBRJEMwQRJBJEMwQUMQASRDMEEiMSRDMBATMCAQgzAwEIMwQBCDUBQgF8MgQhBhJENwEcATEAE0Q3ARwBMwQUEkQzAgAxABNEMwIUMQASRDMDADMCABJEMwIRJRJEMwMUMwMHMwMQIhJNMQASRDMDESMzAxAiEk0kEkQzBAAxABJEMwQUMwIAEkQzAQEzBAEINQFCAREyBCEGEkQ3ARwBMQATRDcBHAEzAhQSRDMDFDMDBzMDECISTTcBHAESRDMCADEAEkQzAhQzBAASRDMCESUSRDMDADEAEkQzAxQzAwczAxAiEk0zBAASRDMDESMzAxAiEk0kEkQzBAAxABNEMwQUMQASRDMBATMCAQgzAwEINQFCAJAyBCEFEkQ3ARwBMQATRDMCADcBHAESRDMCADEAE0QzAwAxABJEMwIUMwIHMwIQIhJNMQASRDMDFDMDBzMDECISTTMCABJEMwEBMwMBCDUBQgA+MgQhBBJENwEcATEAE0QzAhQzAgczAhAiEk03ARwBEkQzAQEzAgEINQFCABIyBCEEEkQzAQEzAgEINQFCAAAzAAAxABNEMwAHMQASRDMACDQBD0OjdHhujKRhcGFhksQEc3dhcMQCZmmkYXBhc5LOAJ+XPc4DuCvcpGFwYXSRxCAEzdCClExhS38IXK2Ty2C4ALvYIPveAQnXc4K5GMZ0K6RhcGlkzgO3q6yjZmVlzQPoomZ2zgFSlVujZ2VurHRlc3RuZXQtdjEuMKJnaMQgSGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiKjZ3JwxCASDWuTSLUW+zDJsUot+B3TCItojg+n8oHeoe7ZC2teaKJsds4BUplDo3NuZMQgS4jy0Gb7ZcISjP2zb5geqse5Tl0YxJsqRg6gs6LDLoSkdHlwZaRhcHBs", "stxn2": "gqRsc2lngaFsxQNcBCAIAQAAva7+BAMEBQYlJA1EMQkyAxJEMRUyAxJEMSAyAxJEMgQiDUQzAQAxABJEMwEQIQcSRDMBGIGs194dEkQzARkiEjMBGyEEEhA3ARoAgAlib290c3RyYXASEEAAXDMBGSMSRDMBG4ECEjcBGgCABHN3YXASEEACOzMBGyISRDcBGgCABG1pbnQSQAE7NwEaAIAEYnVybhJAAZg3ARoAgAZyZWRlZW0SQAJbNwEaAIAEZmVlcxJAAnkAIQYhBSQjEk0yBBJENwEaARclEjcBGgIXJBIQRDMCADEAEkQzAhAhBBJEMwIhIxJEMwIiIxwSRDMCIyEHEkQzAiQjEkQzAiWACFRNUE9PTDExEkQzAiZRAA+AD1RpbnltYW5Qb29sMS4xIBJEMwIngBNodHRwczovL3RpbnltYW4ub3JnEkQzAikyAxJEMwIqMgMSRDMCKzIDEkQzAiwyAxJEMwMAMQASRDMDECEFEkQzAxElEkQzAxQxABJEMwMSIxJEJCMTQAAQMwEBMwIBCDMDAQg1AUIBsTMEADEAEkQzBBAhBRJEMwQRJBJEMwQUMQASRDMEEiMSRDMBATMCAQgzAwEIMwQBCDUBQgF8MgQhBhJENwEcATEAE0Q3ARwBMwQUEkQzAgAxABNEMwIUMQASRDMDADMCABJEMwIRJRJEMwMUMwMHMwMQIhJNMQASRDMDESMzAxAiEk0kEkQzBAAxABJEMwQUMwIAEkQzAQEzBAEINQFCAREyBCEGEkQ3ARwBMQATRDcBHAEzAhQSRDMDFDMDBzMDECISTTcBHAESRDMCADEAEkQzAhQzBAASRDMCESUSRDMDADEAEkQzAxQzAwczAxAiEk0zBAASRDMDESMzAxAiEk0kEkQzBAAxABNEMwQUMQASRDMBATMCAQgzAwEINQFCAJAyBCEFEkQ3ARwBMQATRDMCADcBHAESRDMCADEAE0QzAwAxABJEMwIUMwIHMwIQIhJNMQASRDMDFDMDBzMDECISTTMCABJEMwEBMwMBCDUBQgA+MgQhBBJENwEcATEAE0QzAhQzAgczAhAiEk03ARwBEkQzAQEzAgEINQFCABIyBCEEEkQzAQEzAgEINQFCAAAzAAAxABNEMwAHMQASRDMACDQBD0OjdHhui6RhYW10zgGBEjekYXJjdsQgBM3QgpRMYUt/CFytk8tguAC72CD73gEJ13OCuRjGdCujZmVlzQPoomZ2zgFSlVujZ2VurHRlc3RuZXQtdjEuMKJnaMQgSGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiKjZ3JwxCASDWuTSLUW+zDJsUot+B3TCItojg+n8oHeoe7ZC2teaKJsds4BUplDo3NuZMQgS4jy0Gb7ZcISjP2zb5geqse5Tl0YxJsqRg6gs6LDLoSkdHlwZaVheGZlcqR4YWlkzgCflz0=" }, "unsigned_txn": { "txn1": "i6NhbXTNB9CjZmVlzQPoomZ2zgFSlVujZ2VurHRlc3RuZXQtdjEuMKJnaMQgSGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiKjZ3JwxCASDWuTSLUW+zDJsUot+B3TCItojg+n8oHeoe7ZC2teaKJsds4BUplDpG5vdGXEA2ZlZaNyY3bEIEuI8tBm+2XCEoz9s2+YHqrHuU5dGMSbKkYOoLOiwy6Eo3NuZMQgBM3QgpRMYUt/CFytk8tguAC72CD73gEJ13OCuRjGdCukdHlwZaNwYXk=", "txn2": "iqNhbXTOAGrPwKNmZWXNA+iiZnbOAVKVW6NnZW6sdGVzdG5ldC12MS4womdoxCBIY7UYpLPITsgQ8i1PEIHLD3HwWaesIN7GL39w5Qk6IqNncnDEIBINa5NItRb7MMmxSi34HdMIi2iOD6fygd6h7tkLa15oomx2zgFSmUOjcmN2xCBLiPLQZvtlwhKM/bNvmB6qx7lOXRjEmypGDqCzosMuhKNzbmTEIATN0IKUTGFLfwhcrZPLYLgAu9gg+94BCddzgrkYxnQrpHR5cGWjcGF5" } }

these are encoded txns

after decoding the signed txn from the backend i get

now i am submitting the lsig.l to the submit fuction but getting the error at that time

Expected behaviour

the group txn should submit

Actual behaviour

gitves back a error msgpack decode error [pos 294]: only encoded map or array can be decoded into a struct

https://github.com/algorand/py-algorand-sdk/releases/tag/v2.0.0

All the code from the algosdk.future package is moved directly under algosdk.

So, for example

from algosdk.future.transaction import LogicSigAccount

becomes

from algosdk.transaction import LogicSigAccount

`

I noticed a mismatch of minimum price between the webapp and the SDK.

Here the results of the quote from SDK:

Here a print of the quote: SwapQuote(swap_type='fixed-input', amount_in=ALGO('700'), amount_out=Planets('30848.706199'), swap_fees=ALGO('2.1'), slippage=0.005, price_impact=0.00644)

Here the print of amount expected with slippage: print(quote2.amount_out_with_slippage); Planets('30694.462669')

This is different from what I see in the webapp (since many days)

As you can see the amount_out is correct. However, the amount_out_with_slippage seems to be not correct.

I noticed also that sometimes, even the amount_out does not match. Here I changed th amount_in to 500 ALGO. I am getting the following: SDK: SwapQuote(swap_type='fixed-input', amount_in=ALGO('500'), amount_out=Planets('23341.505158'), swap_fees=ALGO('1.5'), slippage=0.005, price_impact=0.00553)

webapp:

The amount_out in this case is not the same.

This code was working months agso and I was getting exact results between the webapp and the SDK.

Best regards, HHA

https://github.com/tinymanorg/tinyman-py-sdk/blob/40ca5536b7e31d642954ed4e3e9ee773e598c28d/tinyman/utils.py#L108

If any of the elements of signed_transactions is None we should raise an error to inform the user that not all transactions have been signed.

The same applies to client.submit: https://github.com/tinymanorg/tinyman-py-sdk/blob/40ca5536b7e31d642954ed4e3e9ee773e598c28d/tinyman/v1/client.py#L30

https://github.com/tinymanorg/tinyman-py-sdk/blob/40ca5536b7e31d642954ed4e3e9ee773e598c28d/tinyman/utils.py#L103

If the address is not one of the senders we should raise an error. This has tripped up some people who were passing a different address to the one used to generate the transactions but didn't get any error.

PS. Don't be tempted to refactor this to require only a private key and derive the address from that - that won't work for rekeyed accounts.

Hi 👋

I'm trying to get fixed input swap quote and I noticed it's not correct for some pools. In below example PAGO/ALGO pool on the testnet.

from tinyman.v1.client import TinymanTestnetClient

client = TinymanTestnetClient(algod_client)

asset1 = client.fetch_asset(92772865)
asset2 = client.fetch_asset(0)
amount = 80
asset_in = asset1

pool = client.fetch_pool(asset1, asset2)
quote = pool.fetch_fixed_input_swap_quote(asset_in(amount * 10 ** asset_in.decimals), slippage=0.05)

I get the following quote for ALGO out amount and min out amount

while in the Tinyman app I get

which is almost the same but still slightly different.

When I make the transaction from the app the value I receive is matching the minimum value from the app but it seems like the total value (min + excess) is matching the value calculated by the SDK https://testnet.algoexplorer.io/tx/group/MEYPju6fy6LvBzph49xU%2BmvYyj3bpdf4A0FlmYTykU0%3D

Looks like the bug is on the app side not SDK but maybe you can double check it and confirm?

Due to the first transaction in all groups being the same (send 0.002 Algo from sender to escrow for the fees), the transaction ID will be the same if you attempt to create two different swaps and send them within the same round.

The issue is similar to an old bug when you trying to trade 0.002 Algo for any other ASA and the group transaction would fail saying the transaction already exists, The resolution was to add "fee" into the node field. However because when you send two separate swaps each group has its own "fee" transaction with identical parameters, the second group will always fail because the fee transaction already exists in this round (if the round was different and the firstvalid and last valid were shifted by 1 it would be a different txid).

My temporary solution to this was to dump 8 random bytes of data into the note field instead of "fee".