BridgeProvider drops the embedded request and regenerates a connect-only link whenever the universal link exceeds 1024 characters (packages/sdk/src/provider/bridge/bridge-provider.ts:166). That fallback is sound, but the threshold turns out to sit below ordinary payloads rather than pathological ones.
Measuring the fixtures in packages/sdk/tests/provider/bridge/fixtures/universal-link.fixtures.ts, a connect request carrying ton_proof plus two jetton transfers produces a 1066 character link. Over a Telegram attach link, TON plus one jetton transfer is 1033 and two jetton transfers is 1200. The same two-jetton payload without ton_proof fits, so the proof item is what pushes typical requests over the edge.
The practical effect is that "connect and pay in one tap" quietly becomes two steps for a large share of real requests, and the dApp receives dispatched: false with no indication that the payload size was the reason.
I would like to know whether the 1024 budget is meant to accommodate these payloads. If it is, the wire encoding of the embedded request needs to get smaller; if it is not, it would help to document which request shapes can realistically be embedded so integrators do not build flows around a path that rarely triggers.
One smaller thing found alongside: 1024 is written out separately in bridge-provider.ts, in packages/ui/src/app/utils/web-api.ts as MAX_LINK_LENGTH, and in the SDK test, with nothing tying them together.
BridgeProviderdrops the embedded request and regenerates a connect-only link whenever the universal link exceeds 1024 characters (packages/sdk/src/provider/bridge/bridge-provider.ts:166). That fallback is sound, but the threshold turns out to sit below ordinary payloads rather than pathological ones.Measuring the fixtures in
packages/sdk/tests/provider/bridge/fixtures/universal-link.fixtures.ts, a connect request carryington_proofplus two jetton transfers produces a 1066 character link. Over a Telegram attach link, TON plus one jetton transfer is 1033 and two jetton transfers is 1200. The same two-jetton payload withoutton_prooffits, so the proof item is what pushes typical requests over the edge.The practical effect is that "connect and pay in one tap" quietly becomes two steps for a large share of real requests, and the dApp receives
dispatched: falsewith no indication that the payload size was the reason.I would like to know whether the 1024 budget is meant to accommodate these payloads. If it is, the wire encoding of the embedded request needs to get smaller; if it is not, it would help to document which request shapes can realistically be embedded so integrators do not build flows around a path that rarely triggers.
One smaller thing found alongside: 1024 is written out separately in
bridge-provider.ts, inpackages/ui/src/app/utils/web-api.tsasMAX_LINK_LENGTH, and in the SDK test, with nothing tying them together.