ਜਿਹੜੇ ਡਿਵੈਲਪਰਾਂ ਨੇ STON.fi ਟੋਕਨ ਸਵੈਪ (swap) ਨੂੰ ਸੈਂਡਬਾਕਸ (sandbox) ਵਿੱਚ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਕਰ ਲਿਆ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਹੁਣ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ ਕਿ ਜੇਕਰ ਕੋਡ ਵਿੱਚ ਕੁਝ ਮਾਮੂਲੀ ਲੱਗਣ ਵਾਲੇ ਸ਼ਾਰਟਕੱਟ ਛੱਡ ਦਿੱਤੇ ਗਏ, ਤਾਂ ਮੇਨਨੈੱਟ (mainnet) 'ਤੇ ਜਾਣ ਨਾਲ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਫੰਡ ਖਤਮ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਡਿਵੈਲਪਰ ਬਲੌਗ 'ਤੇ ਜਾਰੀ ਕੀਤੀ ਗਈ ਕਮਿਊਨਿਟੀ-ਲਿਖਤੀ ਚੈੱਕਲਿਸਟ ਉਹਨਾਂ ਸਹੀ ਨੁਕਤਿਆਂ ਦੀ ਰੂਪਰੇਖਾ ਦਿੰਦੀ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (integrations) ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ-ਰੇਡੀ (production-ready) ਲਾਂਚ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਤਰੀਕਾ ਪੇਸ਼ ਕਰਦੀ ਹੈ।

ਇਹ ਤਬਦੀਲੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

STON.fi ਇੱਕ ਰੁਟਰ (router) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ TON ਬਲਾਕਚੇਨ 'ਤੇ ਕਈ DEXes ਵਿੱਚ ਲਿਕਵਿਡਿਟੀ (liquidity) ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। ਉਹ ਪ੍ਰੋਜੈਕਟ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕ-ਕਲਿੱਕ ਸਵੈਪ ਦੀ ਸਹੂਲਤ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਫਰੰਟ-ਐਂਡ ਜਾਂ ਸਮਾਰਟ-ਕੰਟਰੈਕਟ ਵੈਪਰ (smart-contract wrapper) ਤੋਂ ਰੁਟਰ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ। ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਰੁਟਰ ਐਡਰੈੱਸ ਸਟੈਟਿਕ ਹੁੰਦਾ ਹੈ, ਫੀਸ ਦਾ ਸ਼ਡਿਊਲ ਪਤਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸੈਂਡਬਾਕਸ ਗਲਤ ਦਿਸ਼ਾ ਵਾਲੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਸਹਿ ਲੈਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਮੇਨਨੈੱਟ 'ਤੇ, ਰੁਟਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਫੀਸ ਦੇ ਪੈਰਾਮੀਟਰ ਬਦਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਗਲਤ ਐਡਰੈੱਸ ਅਸਲੀ ਟੋਕਨਾਂ ਨੂੰ ਇੱਕ ਮਰੇ ਹੋਏ (dead) ਕੰਟਰੈਕਟ ਵੱਲ ਭੇਜ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਵਿੱਤੀ ਜੋਖਮ ਇੱਕ ਸੁਚੱਜੇ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਅਤੇ ਅਜਿਹੇ ਨੁਕਸਾਨ ਦੇ ਵਿਚਕਾਰ ਦਾ ਫਰਕ ਹੈ ਜੋ ਰਾਤੋ-ਰਾਤ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ।

ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ: ਵੈਲਯੂਜ਼ ਨੂੰ ਹਾਰਡ-ਕੋਡ ਕਰਨਾ

ਅਸਫਲ ਲਾਂਚਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲਾ ਪੈਟਰਨ ਰੁਟਰ ਐਡਰੈੱਸ ਜਾਂ ਫੀਸ ਕੰਸਟੈਂਟਸ (constants) ਨੂੰ ਹਾਰਡ-ਕੋਡ ਕਰਨਾ ਹੈ ਜੋ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਵੈਧ ਸਨ। ਜਦੋਂ STON.fi ਆਪਣੇ ਰੁਟਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਦਾ ਹੈ—ਜੋ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਜਾਂ ਬੱਗਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਇੱਕ ਰੁਟੀਨ ਘਟਨਾ ਹੈ—ਤਾਂ ਹਾਰਡ-ਕੋਡ ਕੀਤਾ ਐਡਰੈੱਸ ਹੁਣ ਕਿਸੇ ਕਾਰਜਸ਼ੀਲ ਕੰਟਰੈਕਟ ਵੱਲ ਨਹੀਂ ਇਸ਼ਾਰਾ ਕਰਦਾ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਜਾਂ ਤਾਂ ਅਜਿਹੀ ਗਲਤੀ (error) ਦਿੰਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਕਦੇ ਨਹੀਂ ਦੇਖਦੇ ਜਾਂ, ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਚੁੱਪਚਾਪ ਫੰਡਾਂ ਨੂੰ ਅਜਿਹੇ ਐਡਰੈੱਸ ਵੱਲ ਭੇਜ ਦਿੰਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਕਮਿਊਨਿਟੀ ਗਾਈਡ ਇੱਕ ਸਿੰਗਲ ਨਿਯਮ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ: STON.fi REST API ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦਿਓ ਕਿ ਕਿਹੜਾ ਰੁਟਰ ਵਰਤਣਾ ਹੈ।

ਇੱਕ ਸਟੈਪ-ਬਾਈ-ਸਟੈਪ ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ

ਚੈੱਕਲਿਸਟ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚਾਰ ਤਰਕਪੂਰਨ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਦੀ ਹੈ—ਵਾਤਾਵਰਣ (environment), ਕੰਟਰੈਕਟ ਇੰਟਰੈਕਸ਼ਨ, ਫੀਸ ਕੈਲਕੂਲੇਸ਼ਨ, ਅਤੇ ਐਜ-ਕੇਸ ਹੈਂਡਲਿੰਗ (edge-case handling)।

  • ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਜ਼ (environment variables) ਨੂੰ ਜਲਦੀ ਵੈਲੀਡੇਟ ਕਰੋ। ਟੈਸਟਿੰਗ ਦੌਰਾਨ WebSocket endpoint ਅਤੇ REST API base URL ਨੂੰ ਸੈਂਡਬਾਕਸ ਵੱਲ ਰੱਖੋ; ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਮੇਨਨੈੱਟ ਨੋਡਸ (mainnet nodes) 'ਤੇ ਬਦਲ ਦਿਓ। ਇੱਥੇ ਇੱਕ ਟਾਈਪੋ (typo) ਅਸਲੀ ਸਵੈਪ ਨੂੰ ਟੈਸਟ ਰੁਟਰ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਟੋਕਨ ਹਮੇਸ਼ਾ ਲਈ ਲਾਕ ਹੋ ਸਕਦੇ ਹਨ।

  • ਕਦੇ ਵੀ ਕੰਟਰੈਕਟ ਐਡਰੈੱਸਾਂ ਨੂੰ ਇਨਬੈਡ ਨਾ ਕਰੋ। STON.fi API ਵਿਰੁੱਧ ਇੱਕ ਸਿਮੂਲੇਸ਼ਨ ਰਿਕਵੈਸਟ ਚਲਾਓ, ਰਿਸਪਾਂਸ ਤੋਂ ਮੌਜੂਦਾ ਰੁਟਰ ਐਡਰੈੱਸ ਪ੍ਰਾਪਤ ਕਰੋ, ਅਤੇ ਇਸਨੂੰ ਰਨ-ਟਾਈਮ 'ਤੇ ਆਪਣੇ dexFactory (ਜਾਂ ਸਮਾਨ ਕੰਟਰੈਕਟ-ਫੈਕਟਰੀ) ਵਿੱਚ ਭੇਜੋ। ਇਹ ਭਵਿੱਖ ਦੇ ਕਿਸੇ ਵੀ ਰੁਟਰ ਅੱਪਗ੍ਰੇਡ ਅਨੁਸਾਰ ਆਪਣੇ ਆਪ ਅਨੁਕੂਲ ਹੋ ਜਾਂਦਾ ਹੈ।

  • ਫੀਸਾਂ ਦੀ ਗਣਨਾ ਤੁਰੰਤ (on the fly) ਕਰੋ। API ਦੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੇਲੋਡ (configuration payload) ਤੋਂ ਫੀਸ ਪੈਰਾਮੀਟਰ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਫੀਸ-ਮੈਥ ਰੁ

The takeaway is clear: a swap that “works in testing” does not automatically translate to a safe mainnet experience. By driving every critical value—from router address to fee schedule—from the live STON.fi API, and by rigorously exercising error paths before users ever see the interface, developers can protect user funds and preserve trust when they cross the final mile to production.

Source: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0