How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

ไม่มีรายการตรวจสอบใดพิสูจน์ได้ว่าโครงการปลอดภัย จุดประสงค์คือเปิดเผยสิ่งที่ยังไม่ทราบ เปรียบเทียบคำกล่าวกับหลักฐานที่ตรวจสอบได้ และจำกัดความเสียหายที่อาจเกิดขึ้น

บทความนี้มีวัตถุประสงค์เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำด้านการเงิน การลงทุน หรือกฎหมาย ธุรกรรม Web3 อาจทำให้สูญเสียสินทรัพย์ที่โอนไปทั้งหมด

1. ตรวจสอบแหล่งที่มา

ใช้บุ๊กมาร์กที่บันทึกไว้หรือ URL จากช่องทางทางการที่ยืนยันแล้ว
ตรวจสอบอักขระทุกตัวในโดเมน
หลีกเลี่ยงการเชื่อมต่อกระเป๋าเงินผ่านโฆษณา ข้อความที่ไม่ได้ร้องขอ หรือผลการค้นหาที่ไม่น่าเชื่อถือ
เปรียบเทียบที่อยู่สัญญาในเอกสารทางการของโครงการแต่ละแห่ง
ห้ามเปิดเผยวลีกู้คืน (seed phrase) หรือคีย์ส่วนตัวโดยเด็ดขาด

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. ยืนยันเครือข่ายและสินทรัพย์

ก่อนโอนสิ่งใด ให้บันทึก:

เครือข่าย;
ที่อยู่สัญญาโทเคน;
ที่อยู่ผู้รับหรือสัญญาที่ถูกเรียก;
จำนวน;
สินทรัพย์ที่ใช้ชำระค่าธรรมเนียม;
การดำเนินการที่ตั้งใจ

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. ตรวจสอบโค้ดที่นำไปใช้งาน

ในเครื่องมือสำรวจบล็อกเชน:

ค้นหาสัญญาด้วยที่อยู่ทางการ;
ตรวจสอบการยืนยันซอร์สโค้ด;
ตรวจสอบว่าเป็นพร็อกซีหรือไม่;
เปิด implementation ปัจจุบัน;
เปรียบเทียบที่อยู่ทั้งหมดกับเอกสารโครงการ

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. ทำความเข้าใจอำนาจของผู้ดูแลระบบ

ตรวจสอบบทบาทและฟังก์ชัน เช่น:

owner, admin, operator และ upgrader;
หยุดชั่วคราวและเปิดต่อ;
การเปลี่ยนค่าธรรมเนียมหรือขีดจำกัด;
การเปลี่ยนแปลงที่อยู่ที่เชื่อมโยง;
การสร้างโทเคน;
การถอนสินทรัพย์;
การอัปเกรด implementation;
การระงับที่อยู่

สอบถามว่าใครควบคุมคีย์เหล่านี้ มีการใช้ multisig หรือไม่ การเปลี่ยนแปลงมี timelock หรือไม่ และแจ้งผู้ใช้อย่างไร การควบคุมแบบรวมศูนย์ไม่ใช่การฉ้อโกงโดยอัตโนมัติ แต่เป็นการพึ่งพาผู้ควบคุมเฉพาะราย

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. อ่านรายงานการตรวจสอบอย่างถูกต้อง

ตรวจสอบว่า:

รายงานเผยแพร่โดยผู้ตรวจสอบ;
มีการระบุ repository และแฮช commit;
สัญญาที่ใช้งานจริงอยู่ในขอบเขต;
รายงานครอบคลุม implementation ปัจจุบัน;
ยังมีข้อค้นพบที่ไม่ได้แก้ไข;
ทดสอบการแก้ไขซ้ำแล้ว;
องค์ประกอบสำคัญถูกตัดออกจากขอบเขต

การตรวจสอบคือการทบทวนโดยอิสระเพิ่มเติม ไม่สามารถค้นพบข้อบกพร่องทุกอย่าง และไม่ได้ครอบคลุมเว็บไซต์ การจัดการคีย์ โมเดลธุรกิจ หรือการอัปเกรดในอนาคตโดยอัตโนมัติ

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. เปรียบเทียบคำขอกับพฤติกรรม on-chain

ตรวจสอบธุรกรรมหลายรายการในประเด็นต่อไปนี้:

สถานะ;
From and To / Interacted With;
การเคลื่อนไหวของ BEP-20;
การเรียกใช้ภายใน;
log;
ค่าธรรมเนียม;
การเปลี่ยนแปลงยอดคงเหลือและสถานะสัญญา

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Success means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. แยกสินทรัพย์ออกจากภาระผูกพัน

ยอดคงเหลือของที่อยู่ที่มองเห็นเป็นเพียงข้อเท็จจริงหนึ่งประการ ให้ถามว่า:

เปิดเผยที่อยู่ที่เกี่ยวข้องทั้งหมดหรือไม่;
ใครควบคุมสินทรัพย์;
สามารถถอนได้หรือไม่;
มีภาระผูกพันใดต่อผู้ใช้อื่น;
วิธีกำหนดราคาภายนอก;
การเข้าถึงขึ้นอยู่กับบริดจ์ DEX, oracle หรือคู่สัญญาหรือไม่

ยอดโทเคนจำนวนมากไม่ได้พิสูจน์ว่ามีสภาพคล่อง หน่วยจำนวนมากอาจมีมูลค่าที่นำไปใช้จริงได้น้อย

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. อธิบายโมเดลเศรษฐกิจด้วยภาษาที่เข้าใจง่าย

ค้นหาคำตอบที่ชัดเจนสำหรับ:

เงินที่จ่ายมาจากไหน;
ใครชำระค่าธรรมเนียม;
จะเกิดอะไรขึ้นหากไม่มีผู้ใช้ใหม่;
เงื่อนไขการออกและการล็อก;
ความสูญเสียอาจเกิดขึ้นที่ใด;
ผู้ดูแลระบบเปลี่ยนพารามิเตอร์ใดได้บ้าง;
สิ่งที่ขับเคลื่อนราคาโทเคน

หากผลลัพธ์ขึ้นอยู่กับตลาด ผู้เข้าร่วมรายใหม่ สภาพคล่อง หรือการตัดสินใจของทีม ควรระบุการพึ่งพาเหล่านั้นอย่างชัดเจน

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. ควบคุมลายเซ็นและวงเงินอนุญาตของโทเคน

ก่อนยืนยัน ให้ตรวจสอบสิ่งที่กระเป๋าเงินแสดง:

เครือข่าย;
ที่อยู่ที่ถูกเรียก;
ฟังก์ชันหรือการดำเนินการที่อ่านเข้าใจได้;
มูลค่าโทเคนหลัก;
โทเคนและจำนวนวงเงินอนุญาต;
การเปลี่ยนแปลงสินทรัพย์ที่คาดไว้

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

ปฏิเสธการลงนามหากข้อมูลไม่ชัดเจนหรือที่อยู่ต่างจากที่ตรวจสอบไว้ หลังใช้งาน ให้ตรวจสอบและเพิกถอนสิทธิ์ที่ไม่จำเป็นแล้วผ่านเครื่องมือที่เชื่อถือได้

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. รวมความเสี่ยงนอกเชน

แม้แต่โค้ดที่ผ่านการตรวจสอบอย่างดีก็ไม่สามารถป้องกันทุกกรณีต่อไปนี้ได้:

เว็บไซต์หรือ DNS ถูกเข้าควบคุม;
ส่วนขยายเบราว์เซอร์ประสงค์ร้าย;
การขโมยคีย์;
บัญชีโครงการถูกเข้าควบคุม;
ความล้มเหลวของ backend;
การโจมตีแบบวิศวกรรมสังคม;
ข้อจำกัดทางกฎหมาย;
ความล้มเหลวด้านการสนับสนุนหรือการดำเนินงาน

ตรวจสอบเอกสาร ขั้นตอนรับมือเหตุการณ์ ช่องทางแจ้งเตือน และประวัติการเปลี่ยนแปลง ประเมินคำกล่าวทางกฎหมายจากเอกสารจริงและตามเขตอำนาจศาลของคุณ

11. จำกัดความเสียหายที่อาจเกิดขึ้น

แม้หลังจากตรวจสอบเสร็จแล้ว:

เริ่มด้วยจำนวนทดสอบที่น้อยที่สุดซึ่งใช้งานได้จริง;
ใช้กระเป๋าเงินแยกสำหรับ dApp ที่ไม่คุ้นเคย;
อย่าเก็บสินทรัพย์ทั้งหมดไว้ในกระเป๋าเงินที่เชื่อมต่อ;
ห้ามลงนามภายใต้แรงกดดันด้านเวลา;
บันทึกแฮชธุรกรรมและที่อยู่;
ตรวจสอบวงเงินอนุญาตโทเคนเป็นประจำ;
กำหนดขีดจำกัดความเสี่ยงสูงสุดที่สามารถรับได้หากสูญเสียทั้งหมด

คำแนะนำด้านความปลอดภัยอย่างเป็นทางการของ Solidity แนะนำให้จำกัดจำนวนสินทรัพย์ที่ถือไว้ในสัญญา หากมีข้อบกพร่องในโค้ด compiler หรือแพลตฟอร์ม การจำกัดความเสี่ยงช่วยจำกัดความเสียหายได้

รายการตรวจสอบก่อนทำธุรกรรม

Answer yes, no, or unknown:

ฉันได้ตรวจสอบโดเมนแล้ว
ฉันทราบเครือข่ายที่ถูกต้องแน่นอน
ฉันได้ตรวจสอบที่อยู่สัญญาโทเคนแล้ว
ฉันได้ตรวจสอบที่อยู่สัญญาที่ถูกเรียกใช้แล้ว
ฉันทราบสถานะการยืนยันซอร์สโค้ด
ฉันได้ตรวจสอบพร็อกซีและ implementation แล้ว
ฉันเข้าใจอำนาจของผู้ดูแลระบบ
รายงานการตรวจสอบตรงกับเวอร์ชันที่ใช้งานจริง
ฉันได้ตรวจสอบธุรกรรมจริงแล้ว
ฉันเข้าใจแหล่งที่มาของการจ่ายและสถานการณ์ที่อาจขาดทุน
ฉันเข้าใจคำขอลงนาม
วงเงินอนุญาตถูกจำกัดอย่างเหมาะสม
ฉันได้พิจารณาความเสี่ยงด้าน frontend คีย์ และกฎหมายแล้ว
จำนวนทดสอบต้องไม่ก่อให้เกิดความเสียหายร้ายแรง

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

คำถามที่ผู้ใช้ซึ่งรอบคอบควรถาม

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

แหล่งข้อมูลและเนื้อหาอ่านเพิ่มเติม

Solidity Documentation — ข้อควรพิจารณาด้านความปลอดภัย
Ethereum.org — ความปลอดภัยของ smart contract
Ethereum.org — การทดสอบ smart contract
BscScan Information Center — การดูธุรกรรม
BscScan Information Center — ประเภทการยืนยันสัญญา
BscScan Information Center — ที่อยู่คืออะไร?
OpenZeppelin Docs — รูปแบบการอัปเกรดพร็อกซี