ট্রানজ্যাকশন হ্যাশ কী প্রমাণ দেয়

সর্বশেষ হালনাগাদ: 2026-08-12 উৎস যাচাই: 2026-08-10T18:21:02+08:00

Transaction hash হলো নির্দিষ্ট blockchain transaction খোঁজার identifier। এটি network record-এর দরজা খুলে দেয়, কিন্তু একা বলে না কে আপনার client, কোন invoice-এর কাজের জন্য payment, service deliver হয়েছে কি না, recipient account আপনার কি না, কিংবা payment route বাংলাদেশের current rules-এর সঙ্গে সামঞ্জস্যপূর্ণ কি না। Income proof বানাতে hash-কে commercial ও institutional evidence-এর সঙ্গে মিলাতে হয়।

এক বাক্যে hash কী প্রমাণ দেয়?

একটি valid hash নির্দিষ্ট network-এ একটি transaction record শনাক্ত করতে পারে; সেই record থেকে status, block context, sender/recipient, token event, amount, fee ও time-এর কিছু অংশ যাচাই করা যেতে পারে। কোন field সত্যিই দেখা যাবে তা network ও transaction type-এর ওপর নির্ভর করে। Hash string নিজে success বা finality নয়।

Hash invoice, contract, client identity, work acceptance, tax treatment বা legal approval নয়। তাই evidence file-এ label হবে network_transaction_identifier, “পূর্ণ income certificate” নয়।

hash কখন তৈরি হয়?

Ethereum transaction documentation transaction submission-এর পরে hash পাওয়া এবং পরে validator inclusion/finality-এর distinction ব্যাখ্যা করে। User hash পেলেই transaction block-এ included হয়েছে ধরে নিতে পারেন না। Pending, included, reverted/failed ও finalized status আলাদা।

Client withdrawal page-এর reference এবং public chain hash-ও আলাদা হতে পারে। Custodial internal transfer-এ public hash নাও থাকতে পারে। Ledger-এ reference_type লিখুন: public_tx_hash, platform_transfer_id, bank_reference বা অন্য সত্য label। Platform ID-কে blockchain hash বলে দেখাবেন না।

hash copy করার সময় কী পরীক্ষা করবেন?

Source page বা sender record থেকে full value copy করুন। Beginning/end spot-check transcription error ধরতে সাহায্য করে, কিন্তু full compare ভালো। Spaces, ellipsis বা line break যেন value-এর অংশ না হয়। Explorer URL থেকে query parameter বা tracking অংশ hash field-এ নেবেন না।

কোনো real hash এই article-এ sample হিসেবে দেওয়া হয়নি। Fake-looking placeholder user-কে ভুল শিক্ষা দিতে পারে এবং পরে evidence-এ ঢুকে যেতে পারে। Template-এ blank field বা [transaction hash] স্পষ্ট placeholder ব্যবহার করুন, actual row-তে placeholder reject করুন।

network না জানলে hash কি যথেষ্ট?

না। একই-looking identifier ভিন্ন chain context-এ search করা যেতে পারে। Hash-এর সঙ্গে network exact label ও source service লিখুন। Sender “ERC20” বললেও recipient record কোন network-এ আছে তা independently confirm করুন।

Explorer domain official/known কি না যাচাই করুন; phishing link client পাঠালে তা খুলবেন না। Trusted source থেকে network explorer খুলে hash paste করুন। এই article কোনো নির্দিষ্ট explorer URL দেয় না; official protocol docs facts-এর source।

Ethereum record-এ কী কী দেখবেন?

Transaction page-এ সাধারণত status, block, from, to, value, fee/gas ও input; token transfer event থাকলে contract/token, from, to ও amount দেখা যায়। ERC20 USDT amount native ETH value field-এ নাও থাকতে পারে—token event দেখতে হয়। Token symbol alone নয়, contract context দরকার।

Ethereum blocks documentation blocks-এর strictly ordered transaction history ও parent-block linkage ব্যাখ্যা করে। Evidence-এ block number/hash, observed confirmation/finality state ও observation time রাখলে hash কোন ordered history-তে দেখা গেছে বোঝা যায়।

status success হলেই কি recipient paid?

Protocol execution success মানে transaction network rules অনুযায়ী executed। Custodial service সেই token/network deposit support করে, minimum পূরণ হয়েছে, account-এ credit করেছে—এগুলো আলাদা। Recipient address ঠিক হলেও unsupported token contract credit নাও হতে পারে।

তাই চার status রাখুন: network_execution, confirmation/finality, recipient_service_credit, invoice_reconciliation। প্রথমটি success আর শেষ তিনটি unknown হলে “paid” লিখবেন না। Evidence truthfully partial থাকবে।

sender field কি client প্রমাণ করে?

না। Blockchain address legal identity নয়। Sender address client-এর self-custody হতে পারে, exchange hot wallet হতে পারে, payment processor বা third-party payer হতে পারে। Client agreement বা platform statement ছাড়া address থেকে person/company name infer করবেন না।

Client অন্য payer ব্যবহার করলে invoice evidence-এ relationship explanation দরকার। Written confirmation, platform payout statement বা remittance narrative সাহায্য করতে পারে। Hash-এর from field-কে client name column-এ copy করবেন না।

recipient field কি আপনার ownership প্রমাণ করে?

না। Address আপনার receive screen-এ assigned ছিল—এ evidence লাগতে পারে। Custodial deposit address control provider-এর হতে পারে; user account credit internal ledger-এ হয়। Public address থেকে account holder identity জানা যায় না।

Receiving statement, deposit history বা service reference restricted evidence-এ রাখুন। Full address public/shareable report-এ দরকার না হলে mask করুন; original secure file-এ। Ownership prove করতে private key বা seed phrase কখনো দেবেন না।

token amount কীভাবে পড়বেন?

Token transfer event-এর raw amount decimals অনুযায়ী display হয়। Explorer normalized amount দেখাতে পারে। Contract, decimals ও token label context record করুন। Multiple token events থাকলে কোনটি invoice payment তা evidence দিয়ে নির্ধারণ করুন; largest amount ধরে নেবেন না।

Gross sent, token event amount ও custodial credited amount আলাদা হতে পারে। Fee token amount থেকে কাটা কি না service statement দেখুন। Amount unit ছাড়া number অর্থহীন। CSV-তে asset/network fields পাশে রাখুন।

fee field income amount নয় কেন?

Ethereum gas native ETH-তে, TRON fee/resource TRX context-এ, BSC gas BNB-তে হতে পারে। Fee payer sender হলে recipient USDT amount unchanged। Explorer fee-কে USDT income থেকে সরাসরি subtract করবেন না যদি unit ও economic bearer আলাদা।

Fee evidence table-এ amount, currency, payer, source, included_in_received_amount এবং valuation source রাখুন। Platform withdrawal deduction আলাদা component হতে পারে। Hash page protocol fee দেখালেও platform service fee নাও দেখায়।

timestamp কোনটি ব্যবহার করবেন?

Client send message, transaction creation, broadcast, block inclusion, finality observation এবং recipient credit—সব ভিন্ন। Income ledger policy primary event ঠিক করবে। Hash evidence-এ authoritative block timestamp ও observation time দুটো রাখা যায়। Timezone/UTC label দিন।

TRON transaction lifecycle creation time ও containing block-এর on-chain timestamp, broadcast/inclusion/solidification distinction ব্যাখ্যা করে। TRC20 evidence-এ client-created time নয়, confirmed block context separately record করুন।

TRON receipt-এ কোন field পাবেন?

TRON GetTransactionInfoById post-execution receipt-এ transaction ID, total fee, block information, execution result ও event logs দিতে পারে। Hash save করার পাশাপাশি relevant receipt fields ও observation date record করুন।

Execution result ও event logs মিলিয়ে token transfer occurred কি না দেখুন। No result/pending response-কে success করবেন না। API response save করলে endpoint version ও retrieved_at লিখুন; raw JSON sensitive data review করে archive করুন।

TRON solidified মানে income proven কি?

Solidification network confirmation strength নিয়ে; service-income relationship নয়। Solidified transfer ভুল invoice, wrong client, unsupported deposit বা non-business transfer হতে পারে। Hash evidence কেবল technical layer strong করে।

Commercial layer: contract/order, delivery acceptance, invoice, client/payer link। Institutional layer: recipient statement, inward-remittance or AD evidence where applicable। তিন layer মিললে narrative stronger।

BEP20 finality কীভাবে লিখবেন?

BNB Smart Chain API documentation finality states ও finality-aware block query-এর context দেয়। Record-এ observed_at, block_number, finality_status এবং source রাখুন। “কয়েক confirmation” কোনো universal hard-coded number করবেন না; current service/protocol requirement দেখুন।

BEP20 token/network support গ্রহণকারী platform-এর বর্তমান তথ্য থেকে নিশ্চিত করতে হবে। BNB Chain-এর source-এ network ও confirmation/finality context দেখুন; এক network-এর successful hash-কে অন্য network-এর deposit proof হিসেবে ব্যবহার করবেন না।

block context কেন archive করবেন?

Hash search result later interface বদলাতে পারে। Block number/hash, transaction index, status/finality ও retrieved_at note evidence reproducibility বাড়ায়। Screenshot শুধু visible state; raw link/receipt reference থাকলে ভালো।

Reorganization/finality concept কারণে first-seen observation ও later final status আলাদা হতে পারে। Original observation overwrite না করে second check append করুন। Discrepancy হলে investigation status দিন।

explorer screenshot কি যথেষ্ট?

Screenshot editable/croppable এবং context বাদ যেতে পারে। Full original capture, URL/source, capture time এবং visible network রাখুন। Sensitive browser/account info থাকলে redact copy বানান, original restricted রাখুন। Redaction note দিন।

Screenshot-এর সঙ্গে hash text, exported platform statement ও invoice link রাখুন। Fake balance panel, illustrative hash বা recreated UI proof নয়। এই article-এর cover image evidence নয়; শুধুই editorial illustration।

hash ও invoice কীভাবে match করবেন?

একটি evidence map:

record_id → client_alias → invoice_number → agreed amount → payment confirmation → transaction hash → recipient credit → rate/fee record

Invoice amount ও token amount ভিন্ন হলে fee, partial payment বা conversion assumption প্রমাণসহ explain করুন। One hash multiple invoices মেটালে allocation table। One invoice multiple hashes পেলে each payment row ও outstanding balance।

Invoice number blockchain transaction-এ embedded না-ও থাকতে পারে। Client communication ও internal ledger link তৈরি করে। Link নিজে লেখা বলে source documents দরকার।

client identity কীভাবে link করবেন?

Client register-এ alias, contract billing name, contact reference ও payer relationship। Hash address legal name নয়। Platform payout statement sender name দেখালে privacy ও authenticity review করুন। Third-party payer হলে client authorization evidence রাখুন।

Name mismatch অপরাধের proof নয়, কিন্তু unresolved exception। Guess দিয়ে client field পূরণ করবেন না। payer_relationship_unverified status future reviewer-কে gap জানায়।

work delivery proof কেন লাগবে?

Payment transfer সত্য হলেও তা freelance service-এর জন্য কি না hash বলে না। Contract, task scope, delivery file/reference, acceptance email বা marketplace completion record commercial purpose দেখায়। Without delivery evidence, loan, gift, refund বা own-account transfer exclude করা কঠিন।

Evidence minimum project অনুযায়ী বদলে যায়। Unnecessary client confidential files ledger-এ রাখবেন না; document reference যথেষ্ট হতে পারে। Access control ও retention terms মানুন।

official Freelancer ID documents কী boundary শেখায়?

Freelancer ID essential documents proof-এ name, income amount ও transaction date এবং direct-client work evidence-এর সঙ্গে corresponding inward-remittance proof-এর requirement দেখায়। Hash একা name বা service relationship দেয় না।

Application-এ portal-এর current accepted documents ব্যবহার করুন। Hash supporting technical record হতে পারে, কিন্তু listed financial statement/remittance proof-এর substitute ধরে নেবেন না। Approval guarantee নয়।

fiat value hash থেকে সরাসরি পাওয়া যায়?

না। Hash token amount ও timestamp anchor দিতে পারে; historical fiat rate external/manual source থেকে আসে। Rate value, currency direction, source ও observation time আলাদা রাখুন। fiat_value = chosen_asset_amount × manual_rate।

Explorer-এর current price banner historical payment value নাও হতে পারে। আজকের price দিয়ে পুরোনো transaction revalue করলে label দিন; original payment-date record নয়। Actual bank credit থাকলে separate evidence।

hash duplicate হলে কী করবেন?

Same hash দুই income row-এ থাকলে duplicate review। Legitimate multi-invoice allocation হলে transaction total একবার এবং allocations sum transferred/credited amount-এর সঙ্গে মেলে। Duplicate copy error হলে extra row void/corrected, delete নয়।

Different network-এ same text value theoretical context হলেও network key composite করুন: network + hash। Case normalization rule documentation-এ লিখুন; original value retain।

failed transaction কি record-এ থাকবে?

হ্যাঁ, যদি attempt business/payment history-এর অংশ এবং fee/cost হয়েছে। Status failed, received amount zero where evidenced, fee actual with currency, retry link। Failed hash income total-এ নয়, exception/attempt log-এ।

Retry new hash। Old failed record overwrite করবেন না। Client-কে success বলে জানালে correction communication reference রাখুন। Failed attempt legal/payment-route প্রশ্ন বদলায় না।

internal transfer হলে কী করবেন?

নিজের account-এর মধ্যে movement service income নয়, unless underlying client receipt separately linked। Public hash own-transfer হতে পারে। Classification field self_transfer, client_payment, refund, unknown—evidence-based। Unknown-কে income total-এ নেওয়ার আগে review।

Custodial platform internal transfer public chain-এ না গেলে platform ID ও statement। Fabricated hash বানাবেন না। “No public hash—internal record only” honest field।

privacy কীভাবে রক্ষা করবেন?

Public blockchain data public হলেও client alias, invoice ও identity একত্র করলে sensitive business profile হয়। Shareable report-এ minimum fields, masked addresses এবং evidence reference দিন। Full bundle restricted।

Hash share করা কখন দরকার তা recipient/purpose অনুযায়ী ঠিক করুন। Secret কখনো নয়। Official support ticket-এ requested fields দিন, social-media stranger-কে নয়। Access log ও retention policy রাখুন।

Bangladesh regulatory boundary কী?

বাংলাদেশ ব্যাংকের FE সার্কুলার No. 24 in/from/to Bangladesh specified virtual-asset transaction এবং exchange/transfer/trading facilitation-এর নিষেধমূলক সীমা জানায়। Hash সংরক্ষণ transaction route-কে অনুমোদিত করে না। Technical success legal approval নয়।

Past event-এর liability বা remedy এই article নির্ধারণ করে না। Further transfer/conversion শুরু না করে true records preserve করুন এবং Bangladesh Bank, AD ও qualified professional-এর current written advice নিন। Evidence guidance regulatory bypass নয়।

evidence card-এ কোন field থাকবে?

Record ID: ___ Network: ___ Reference type: public hash / platform ID / other Transaction hash/reference: ___ Block number/time: ___ Execution status: ___ Finality/confirmation status: ___ Token/contract: ___ Sender address/reference: ___ Recipient address/reference: ___ Asset amount: ___ Protocol fee and currency: ___ Recipient credit status: ___ Invoice/client evidence reference: ___ Observed at: ___ Exception: ___

Blank card real evidence নয়। Actual source values হাতে পূরণ করবেন এবং reviewer যাচাই করবেন। No secret fields।

proof strength কীভাবে grade করবেন?

• Level 1: hash string only; network/status unverified।
• Level 2: network record verified; status, token, amount, addresses/time captured।
• Level 3: recipient credit statement linked।
• Level 4: invoice, client/payer ও work evidence linked।
• Level 5: relevant institutional/remittance evidence linked and professional review noted।

এই internal scale official standard নয়। Higher level legal acceptance guarantee নয়। Data dictionary-তে definition দিন; grade change log রাখুন।

কোন false claim এড়াবেন?

• “Hash আছে, payment final”—status না দেখে নয়।
• “From address client-এর”—identity evidence ছাড়া নয়।
• “To address আমার”—assignment/account evidence ছাড়া নয়।
• “Success মানে balance usable”—recipient credit ছাড়া নয়।
• “USDT amount মানে USD cash”—valuation/receipt ছাড়া নয়।
• “Invoice paid”—allocation ও commercial link ছাড়া নয়।
• “Record আছে, তাই legal”—regulatory decision ছাড়া নয়।

Precise সীমা trust বাড়ায়; technical complexity দিয়ে missing evidence ঢাকবেন না।

মাস শেষে hash review কীভাবে করবেন?

1. Network+hash uniqueness check।
2. Pending/failed/finalized status refresh with observed_at।
3. Token contract/amount verify।
4. Recipient credit reconcile।
5. Invoice allocation sum check।
6. Client/payer relationship exceptions।
7. Payment time/rate record link।
8. Fee currency/bearer review।
9. Refund/retry links।
10. Privacy/shareable export check।

Review-এর পরে original observations preserve করুন। Status update append হবে।

শেষ সিদ্ধান্ত কী?

Hash হলো technical locator, income proof bundle নয়। Strong record-এ network execution, confirmation/finality, recipient credit, client/invoice/work relationship, valuation এবং applicable institutional evidence আলাদা স্তরে থাকে। Hash এই স্তরগুলো join করার key হতে পারে; missing স্তর নিজে তৈরি করে না।

explorer unavailable হলে evidence কীভাবে রাখবেন?

Explorer সাময়িকভাবে না খুললে hash, network, observed error, check time এবং ব্যবহৃত public endpoint-এর নাম লিখুন। পুরোনো screenshot থেকে success অনুমান করবেন না। Receiving platform-এর credit record থাকলে সেটি আলাদা স্তরের evidence হিসেবে রাখুন, কিন্তু chain status-এর বিকল্প বলে label দেবেন না। পরে explorer ফিরে এলে একই hash ও network পুনরায় পরীক্ষা করে rechecked_at যোগ করুন। একাধিক explorer ভিন্নভাবে label দেখালে raw field ও block reference তুলনা করুন; সুবিধাজনক label বেছে নিয়ে বিরোধ লুকাবেন না। Availability সমস্যা transaction failure-এর প্রমাণ নয়, আবার success-এর প্রমাণও নয়।

token contract কেন record-এ দরকার হতে পারে?

একই ticker বহু network বা contract-এ দেখা যেতে পারে। তাই explorer থেকে asset label copy করার পাশাপাশি source chain, token contract বা asset identifier visible থাকলে লিখুন। Contract address কোনো chat message থেকে অনুমান করবেন না এবং এই article কোনো contract তালিকা দিচ্ছে না। Receiving platform যে exact asset-network pair credit করেছে তার record আলাদা রাখুন। Hash success হলেও unsupported representation income হিসেবে usable হয়েছে—এটি নিজে প্রমাণ করে না। Contract field না পাওয়া গেলে not captured লিখুন; পরিচিত ticker দেখে fabricated value বসাবেন না।

confirmation policy বদলালে পুরোনো record কী হবে?

আপনার internal confirmation threshold পরে বদলাতে পারে, অথবা platform নতুন finality rule জানাতে পারে। পুরোনো observation মুছবেন না। observed_confirmations, observed_at, policy_version এবং review_result রাখুন। নতুন policy দিয়ে পুনরায় review করলে দ্বিতীয় observation যোগ করুন। “Final” শব্দটি explorer বা protocol context-এ কী বোঝায় তা source অনুযায়ী লিখুন; commercial acceptance, withdrawal availability ও legal acceptance একই বিষয় নয়। Policy change-এর পরে সব পুরোনো hash approved বলে mass-update করলে evidence chronology হারিয়ে যায়।

reorganization বা status change কীভাবে নথিভুক্ত করবেন?

প্রথম observation-এর পরে block বা status বদলালে before/after evidence রাখুন। Original screenshot, block number, status, confirmation count ও time সংরক্ষণ করুন; পরে দেখা state আলাদা record হিসেবে যোগ করুন। Receiving ledger-এ amount usable হয়ে থাকলেও discrepancy unresolved থাকতে পারে। Client-কে নিশ্চিত উত্তর দেওয়ার আগে current network record ও receiving platform record দুটো যাচাই করুন। একটি status change দেখে recovery, reversal বা compensation নিশ্চিত করবেন না। এই chronology technical investigation-এ সাহায্য করে; টাকা ফেরত পাওয়া বা credit হওয়ার নিশ্চয়তা দেয় না।

batch payment-এ একটি hash কী বোঝাতে পারে?

কখনো একটি transaction-এ একাধিক transfer event থাকতে পারে, অথবা platform internal accounting একটি visible transaction-এর সঙ্গে একাধিক user credit মিলাতে পারে। তাই hash পেলেই পুরো transaction value আপনার income বলে ধরে নেবেন না। Relevant transfer event, recipient, asset, amount এবং platform credit reference চিহ্নিত করুন। Event index বা log reference পাওয়া গেলে evidence card-এ রাখুন। Invoice-এর expected amount-এর সঙ্গে শুধু top-level value মেলানো ভুল হতে পারে। Source interface field না দেখালে event detail unavailable লিখুন এবং stronger receiving evidence চান।

client-submitted hash যাচাইয়ের neutral reply কী হতে পারে?

Reply-তে বলুন যে hash পেয়েছেন, কিন্তু network, status, recipient event, amount এবং receiving credit যাচাই বাকি। Verification শেষ হওয়ার আগে “payment received” বলবেন না। Mismatch পেলে exact field জানান—যেমন agreed network-এর সঙ্গে পাঠানো network মেলেনি বা transaction successful হলেও account credit দেখা যায়নি। Client-কে private key, seed phrase, login code বা remote access চাইবেন না। Support দরকার হলে platform-এর official support route ব্যবহার করতে বলুন। Neutral language dispute কমায় এবং technical evidence ও commercial acceptance আলাদা রাখে।

archive export-এর integrity কীভাবে পরীক্ষা করবেন?

Evidence folder export করার পরে file list, size এবং cryptographic checksum-এর একটি local manifest রাখা যায়। এটি পরে accidental change শনাক্ত করতে সাহায্য করে; document সত্য বা transaction lawful প্রমাণ করে না। Screenshot-এর সঙ্গে text note রাখুন যাতে search করা যায়। File name-এ hash-এর সংক্ষিপ্ত অংশ ব্যবহার করলে collision এড়াতে record ID ও network-ও যোগ করুন; public report-এ full address বা client identity প্রকাশের আগে privacy review করুন। Backup copy খুলে দেখা যায় কি না পরীক্ষা করুন। শুধু backup আছে লেখা এবং restore test করা এক বিষয় নয়।

সম্পাদকীয় সীমা: এই লেখা transaction evidence পড়া ও archive করা নিয়ে; wallet access, recovery promise, live price, private exchange, tax/legal determination বা prohibited activity facilitation নয়। Sources 2026-08-10T18:21:02+08:00-এ দেখা হয়েছে। Bangladesh-specific current handling Bangladesh Bank, AD ও qualified professional-এর কাছে যাচাই করুন।