Testnet task record بنائیں: کام کا ثبوت رکھیں، wallet کا secret نہیں

الگ task record کس مسئلے کو حل کرتا ہے؟

Record “میں نے یہ کیا تھا” کو official URL، wallet alias، chain ID، action اور transaction hash سے قابل جانچ بناتا ہے۔ Project interface بدل سکتا ہے، community channel archive ہو سکتا ہے، اور wallet list method کا مقصد نہیں بتاتی۔ Context کے بغیر hash اور chain proof کے بغیر screenshot دونوں ادھورے ہیں۔

اچھی row چھ سوالوں کا جواب دیتی ہے: کون سا project؛ official entry کہاں سے ملی؛ کون سا wallet؛ کون سی chain؛ کیا action؛ chain اور app کی الگ حالت۔ Expected reward، social rumor اور ذاتی خیال notes میں جائیں، confirmed fact میں نہیں۔ Task log شرکت دکھاتا ہے، reward یا آمدنی کی ضمانت نہیں۔

Record duplicate risk بھی کم کرتا ہے۔ وہی campaign دوبارہ ملے تو معلوم ہو سکتا ہے کہ پرانا spender allowance باقی ہے، faucet rate limit تھا، main wallet غلطی سے استعمال ہوا، یا network migration کے بعد old contract کھلا ہے۔ Bookmark permission history نہیں بتاتا۔

Support کے وقت “کام نہیں ہوا” کے بجائے chain ID، exact error، request ID اور hash دیا جا سکتا ہے۔ Genuine maintainer public data سے issue دیکھ سکتا ہے؛ secret مانگنے کی ضرورت نہیں۔

Task sheet میں کون سی چیز کبھی نہ لکھیں؟

Seed phrase، private key، wallet password، email یا exchange OTP، API key، session cookie اور remote-control code task record میں نہ ہوں۔ Local file بھی malware، accidental share، cloud sync یا device repair کے دوران leak ہو سکتی ہے۔ عام spreadsheet کو key vault بنانا خطرناک ہے۔

Shared team sheet میں full public address بھی need-to-know basis پر رکھیں۔ Shared table میں alias ہو سکتا ہے، alias-to-address mapping کم permission والی local file میں۔ اس طرح status update کرنے والا ہر شخص پورا wallet profile نہیں دیکھتا۔

Public address secret نہیں، مگر مکمل history، balance اور counterparties سے linked ہے۔ اسے social account یا حقیقی شناخت سے ملایا جائے تو privacy کم ہوتی ہے۔ Public ہونے کا مطلب بلا ضرورت ہر جگہ نشر کرنا نہیں۔ Screenshot share کرنے سے پہلے tabs، bookmark bar، extension icons، email اور غیر متعلق balance چھپائیں۔

ایک task row میں واقعی کون سے fields چاہییں؟

Project identity، verified entry، wallet alias، network، action، on-chain evidence، app status اور next step رکھیں۔ بہت زیادہ fields بھرے نہیں جاتے؛ بہت کم fields بعد میں کچھ نہیں بتاتے۔ یہ فہرست عام testnet کے لیے مناسب آغاز ہے۔

Project identity

• Project/phase: Official نام اور alpha، testnet، devnet یا campaign label۔
• Entry URL: مکمل link اور یہ homepage، docs یا official repository سے ملا۔
• Verification date: وہ حقیقی تاریخ جب link ملایا؛ یہ دائمی guarantee نہیں۔
• Change notice: Network، contract یا rule بدلے تو اصل announcement link۔

Wallet اور network

• Wallet alias: T01 یا T02؛ seed کا اشارہ نہیں۔
• Public address: Chain query کے لیے full address، shared view میں alias کافی ہو سکتا ہے۔
• Network/chain ID: دونوں ساتھ؛ custom label اکیلا reliable نہیں۔
• RPC source: Official docs یا provider page، API key والا private URL نہیں۔
• Contract: Actual interaction address اور verification source۔

Action اور result

• Task action: Faucet، swap، deploy، mint، vote یا bridge، صرف “done” نہیں۔
• Request type: Connect، message sign، approve، permit، transaction یا social link۔
• Transaction hash: ہر on-chain action کی الگ row۔
• On-chain status: pending، success یا failed اور explorer URL۔
• App status: complete، indexing، failed یا not started، chain سے الگ۔
• Error: اصل متن copy، اپنی تشریح الگ note۔
• Next action: Retry، revoke، announcement یا support ticket کا واضح قدم۔

Task کرتے وقت record کس ترتیب سے بھریں؟

Sign سے پہلے row بنائیں، confirmation کے بعد hash ڈالیں، page چھوڑنے سے پہلے status اور next action لکھیں۔ دن کے آخر میں یاد سے سب بھرنے پر addresses اور networks مل جاتے ہیں۔ Critical points پر مختصر update زیادہ درست ہے۔

1. داخل ہونے سے پہلے: Official source سے URL، project phase اور check date درج کریں۔
2. Connect سے پہلے: Wallet alias، public address، network اور chain ID ملائیں۔
3. Popup سے پہلے: Request type، contract/spender اور expected action لکھیں۔ سمجھ نہ آئے تو “Stopped—unclear request” لکھ کر cancel کریں۔
4. Transaction کے بعد: Hash فوراً copy اور صحیح explorer کا full link محفوظ کریں۔
5. Page response کے بعد: Chain اور app status الگ update کریں؛ اختلاف ہو تو دونوں کو زبردستی complete نہ کریں۔
6. Session بند کرنے سے پہلے: Allowance review، disconnect، retry یا support کا next step لکھیں۔

ایک task میں کئی transactions ہوں تو Task group ID دیں۔ مثلاً T014 کے تحت faucet، approve، swap اور vote الگ rows ہوں۔ کسی step کی ناکامی، dependency اور بعد میں revoke کرنے والا spender واضح رہتا ہے۔

Social task میں platform اور permission scope لکھیں، password یا login token نہیں۔ Discord role app status میں لکھا جا سکتا ہے۔ X یا GitHub حقیقی identity سے linked ہو تو privacy note شامل کریں تاکہ بعد میں unlink کا فیصلہ ہو سکے۔

Transaction hash، screenshot اور app status ایک دوسرے کی جگہ کیوں نہیں لے سکتے؟

Hash بتاتا ہے chain پر کیا ہوا؛ screenshot دکھاتا ہے اس وقت interface کیا کہہ رہا تھا؛ app status project database کا نتیجہ ہے۔ Green “Completed” screenshot transaction confirmation نہیں، اور success hash campaign credit کی guarantee نہیں۔ تینوں کو ان کے نام سے رکھیں۔

Hash کے ساتھ network لازمی

EVM chains میں hash format ملتا جلتا ہو سکتا ہے۔ Chain ID اور full explorer URL نہ ہو تو بعد میں network معلوم کرنا مشکل ہے۔ From، To، status، method اور token changes دیکھیں۔ Proxy کی implementation نظر آئے تو observed information لکھیں؛ code سمجھے بغیر “safe” verdict نہ دیں۔

Screenshot محدود اور صاف

Error، request number، domain اور relevant task area کافی ہیں۔ مکمل desktop، inbox، bookmarks، extensions، دوسرے balances یا phone notifications نہ لیں۔ Filename میں project abbreviation، group ID، step اور حقیقی date استعمال ہو سکتی ہے، مثلاً alpha-T014-faucet-error-2026-07-21.webp۔ مصنوعی precise time نہ بنائیں۔

Evidence file الگ directory میں

بڑی image ہر spreadsheet cell میں embed کرنے سے backup بھاری اور access control مشکل ہوتا ہے۔ Project folder میں images، table میں filename اور purpose رکھیں۔ Cloud link public نہ ہو۔ Delete/archive کے وقت متعلقہ evidence آسانی سے ملے گا۔

Support کے لیے crop کرتے وقت domain اور error باقی رہیں۔ Transaction hash text میں بھی دیں تاکہ copy ہو۔ Identity document، KYC image یا seed backup کبھی task evidence نہیں۔

Record کب review اور project کب close کریں؟

Fixed weekly promise کے بجائے events پر review کریں: high permission کے بعد، official change پر، اور participation ختم کرتے وقت۔ قابل عمل trigger کاغذی schedule سے بہتر ہے۔

• Approval کے بعد: Spender، amount اور chain expected ہیں؛ task ختم ہو تو revoke کا فیصلہ۔
• Network migration: Old row overwrite نہیں؛ نئی chain ID، contract اور notice کے ساتھ نئی row۔
• Contract update: Old/new addresses الگ اور official source link۔
• App-chain mismatch: Explorer پہلے، پھر request ID اور hash کے ساتھ support۔
• Project pause: Pending action روکیں، connections اور social permissions دیکھیں۔
• Exit: غیر ضروری allowance revoke، site disconnect، sensitive attachments delete، row Closed۔

Reward date یا amount community rumor ہو تو “Unverified” لکھیں، fact column نہیں۔ Project eligibility بدل یا reward ختم کر سکتا ہے۔ Record participation history ہے، مالی وعدہ نہیں۔

Close کے بعد minimal archive مفید ہو سکتا ہے: project، alias، chain، contract، final permission state اور close date۔ غیر ضروری screenshots اور identity attachments حذف کریں۔ Data رکھنے کی وجہ نہ ہو تو کم data زیادہ محفوظ ہے۔

Copy کرنے کے لیے secret-free testnet template

اس table میں secret کا کوئی field نہیں۔ Local spreadsheet، encrypted note یا CSV میں استعمال کریں۔ Team share سے پہلے address اور evidence permissions الگ کریں۔

CSV میں multiline error columns توڑ سکتا ہے۔ Full error الگ text file میں اور table میں summary/filename رکھیں۔ Long address یا hash کو spreadsheet scientific notation میں نہ بدلے، اس لیے text format منتخب کریں۔ Address پر formula نہ چلائیں۔

Backup رکھیں مگر secret-free design قائم رہے۔ Cloud account پر 2FA اور limited sharing استعمال کریں۔ Backup encryption risk کے مطابق منتخب کریں۔ Record کھونا تکلیف ہے، secret leak ہونے سے کم؛ دونوں کو ایک file میں رکھ کر خطرے نہ ملائیں۔

کمزور record کی پانچ نشانیاں

1. ہر row میں صرف “Done”، network، address یا hash نہیں۔
2. Screenshot ہی chain evidence ہے، explorer status نہیں۔
3. ایک cell میں کئی hashes، action کا تعلق نامعلوم۔
4. Convenience کے لیے password یا seed کا field۔
5. Community rumor کو confirmed reward لکھا گیا۔

Record لمبا ہونا مقصد نہیں۔ جو field فیصلہ، troubleshooting یا close-out میں استعمال نہ ہو اسے ہٹا دیں۔ ایک note بار بار آئے تو field بنائیں۔ Alias scheme مستقل رکھیں؛ پرانا alias نئے wallet کے لیے recycle نہ کریں۔ مستقبل میں پانچ منٹ میں row سمجھ آنا اصل usability test ہے۔

عام سوالات

بنیادی حوالہ جات

• Ethereum.org: Block explorers
• Ethereum.org: Transactions
• MetaMask Support: Wallet activity
• OWASP: User Privacy Protection
• GitHub Docs: Task lists
• OWASP Top Ten