Postcondition number different from contract call

[zhigang1992]

What version of Stacks.js are you using?

"@stacks/connect": "^7.2.1",
"@stacks/transactions": "^6.11.0",

Describe the bug

When creating post condition with a very big number, the amount will turn into a random number

How to reproduce

const stxAddress = userData!.profile.stxAddress.mainnet;
const amount = 100000000000000000000n
await openContractCall({
  anchorMode: AnchorMode.Any,
  contractAddress: 'SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9',
  contractName: 'age000-governance-token',
  functionName: 'transfer-fixed',
  functionArgs: [uintCV(amount), principalCV(stxAddress), principalCV('SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9'), optionalCVOf(undefined)],
  postConditions: [createFungiblePostCondition(stxAddress, FungibleConditionCode.Equal, amount, 'SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.age000-governance-token::alex')]
});
}}

Expected behavior

Reproduce repo:

https://github.com/alexgo-io/post-condition-example

[janniks]

Post-conditions can only handle amounts up to 8-byte length. I'm adding a check to serialization that will throw if the amount is larger.

[janniks]

Added a check here: https://github.com/hirosystems/stacks.js/pull/1612/files
It depends on your use-case, but it should be possible to check for the byte-length of the amount users want to send. According to SIP-005 in Stacks we can only post-condition for amounts up to 8-bytes integer length.

[janniks]

Also Stacks transfers can only send amounts up to 8-bytes in length.

[fiftyeightandeight]

Also Stacks transfers can only send amounts up to 8-bytes in length.

Hi @janniks so you mean if post-condition fails due to 8-bytes length, then the underlying transfer should also fail?

[janniks]

Stacks transfer transactions (STX or other fungible tokens) are encoded to only have 8-bytes of "amount" information in the wireformat (the same goes for post-conditions). This is a part of SIP-005.
So we can't encode more than 8-bytes for the amount value, trying to would cut off the amount in serialization/deserialization code.