Market signal
Exact BTC output verification
Evergreen NOVA operator education for guarded Polymarket BTC signal execution.
View market source →Crypto payment verification sounds simple until the edge cases matter.
For NOVA, the important number is not the miner fee. It is not the wallet's total spend. It is the output amount sent to the deposit address.
That distinction matters because payments often sit at the boundary between buying access and unlocking setup. If the payment check is loose, the system can move the wrong user or wrong invoice forward.
What an output proves
A Bitcoin transaction can include more than one output. One output may go to the merchant. Another may return change to the sender. Fees are paid to miners and do not arrive at the deposit address.
So the verification question is specific: did this transaction include an output to the NOVA deposit address for the expected amount?
That is the amount that should unlock the next setup step.
An operator should store the transaction id, destination address, expected amount, received output amount, confirmation count, and final verification decision. Without those fields, a later support issue becomes guesswork.
Why exact amount checks matter
If a setup only checks that "some BTC arrived," it can confuse invoices. One buyer might underpay. Another might send the right amount later. A shared deposit address makes this even more important.
NOVA currently uses the BTC deposit address:
1CBg5veNG9TAMLdstffcfQkyVxM6qvL4uL
When a shared address is used, exact amount verification helps separate one payment from another. The stronger long-term setup is a unique invoice per buyer with a unique amount or a unique address.
Exact amount checks also reduce false positives. If the system only sees that BTC arrived somewhere, it may confuse change outputs, partial payments, overpayments, or unrelated deposits. The check should be tied to the invoice being reviewed.
Overpayment is a policy decision
Some systems accept overpayment. Some require an exact amount. NOVA should keep that policy explicit.
For controlled onboarding, exact payment is cleaner. It avoids a case where the system unlocks setup from a transaction that was not meant for that invoice.
If overpayment is allowed later, it should be a policy choice, not an accident. The system should record that the invoice was accepted even though the received output was higher than expected. That record protects both the buyer and the operator.
Confirmations still matter
A transaction can appear before it has enough confirmations. The required confirmation count should match the value of the setup being unlocked.
For low-risk checks, one confirmation may be acceptable. For larger payments or account changes, the system can require more. The key is to store the invoice, expected amount, transaction id, confirmation count, and final verification result before changing access.
Payment status should not be inferred from a screenshot. Screenshots are useful for support, but the unlock should come from a verifiable chain lookup and a stored invoice match.
For NOVA, the safe order is:
- Create or identify the invoice.
- Watch the expected address and amount.
- Match the exact output.
- Wait for the required confirmations.
- Store the result.
- Unlock the next setup step.
What not to use as proof
Do not unlock setup from a wallet screenshot alone. Do not unlock setup from a transaction total without checking the destination output. Do not unlock setup because a buyer says the fee made the amount look different.
Fees affect what the sender spent. The output amount is what the deposit address received. That is the value the invoice should check.
Why this belongs in an automation checklist
Payment verification sounds separate from trading automation, but it controls access. If payment status is wrong, the wrong setup can move forward.
For a guarded bot, every gate should be explicit: payment, credential review, no-submit preview, risk cap, and live approval. The payment gate is simply the first one many buyers see.
The operator takeaway
Payment verification should be boring and exact. NOVA should verify the output amount sent to the deposit address, store the result, and only then move the setup forward.
That is not just an accounting detail. It is part of the same guardrail system as no-submit mode, credential review, and risk caps.