Bug reports (public)

Transaction hash: 0x634e31846d02d62403512c386fb75fdea2ab9ce99be132128ab4bd2dbbfe6739 Clear description of the problem: The incorrect breakdown of 1 swap into 3 transactions HyperSwap HYPE protocol by StHype Impact: The creation of an apparent gain that doubles the real one affecting tax reporting Specific Request: Problem Review and Correction

When selecting the type of transaction to add, the “transfer” option is no longer available, is that normal? Thanks in advance for your help.

When manually adding a withdrawal transaction, it cannot be changed anymore to transfer in the dropdown menu. This means I am not able to manually add transfers anymore.

The bulk export feature consistently returns a 404 error, while all other site functionality works as expected. Bulk export should complete successfully and provide the exported file, but it fails with a 404 error. No other features are affected. Troubleshooting already attempted: -Cleared cache and cookies -Tried logging in through http://api.koinly.io/cf - this clears Cloudflare's cache, which can cause these page errors. -Tested across multiple browsers -Verified user permissions -No VPN confirmed -Confirmed endpoint availability for other features Impact: Prevents users from exporting data in bulk, affecting workflow efficiency. Per Fin, requires developer investigation into the bulk export endpoint or related routing logic.

Following the recent notification re security incident on the Third-party platform Mixpanal. KOINLY needs to implement decentralisation of all client data (our data) so that it is impossible for bad actors to get hold of our home address, phone numbers, emails and other personal data even if the is a data breach on Third-Party Platform like Mixpanel, we are putting our trust in you Koinly

I'm trying to filter spam (SOL dust), so made a rule based on the source wallets. But Koinly seems unable to identify the source on some transactions (even though to me, they look like virtually identical transactions, including the same source wallets). Here are two of the bulk dust transactions where Koinly nicely identifies the source, so the rule works for these. PLFeF9F4xbDjQjgFKVXwutR2vtFZhKHLPrpvC5B7k78Zed6Bbndnwd8r4LMmBjQ1hm9Ay29CJSQM9WMbJBTaZQ7 3oKBFtuVLkDXy6nkeZVCZzJgabbMcU6NyCBa9VrWYas4NXfYFQC6BAeBesywjMfjaCy8YUr1RAFZ8pRrfqteiLyM Here are some more, where Koinly seems unable to identify the source, so the rules don't work. (note these are coming from the _same_ wallets, as you can see in a block explorer) 5yJnxgKLr8vtzhb3oYyuxipSg1FQHSqUjNkpfkZbEWzRcwMVLKEGaAeaAoX9KYQbPvUoRiUDmo84axrC4AsvGUjH NKtuJkuvWxgDCndUrRTGzdrxtbv6v6n9oZvSvJ7r6MRURrC4gi8sLAeQBnCAFiyPcEVrXJpNudrd3YWEZpqQTz2 See image for the difference in UI where it can determine source vs not.

Strike recently changed their CSV statements and it doesn't import into Koinly. Can this please be updated?

When wallet-based cost tracking is enabled, it fails to preserve acquisition lineage for fork-origin staking across pool transfers (HEX on PulseChain for example). Balances reconcile, but HIFO reports missing purchase history for a deterministic subset. This is a showstopper, as you are no longer are able to utilize Pool ins / Outs, which is key to achieve basis carryover on the principal (required by Rev Rule 2023-14)

Hi, The way that crypto gains are taxed in France is very wrong. https://koinly.io/fr/guides/crypto-tax-france/#cost-basis-method While the formula is correct, the example is utterly broken. The total acquisition cost should include the acquisition cost of the whole portofolio. Once that is fixed, the actual cost basis is calculated at step 2. Gain is calculated at step 3. Step 4 is rubish. To put it sanely : When cashing 10% of your portofolio (2000€ sale price on a 20000€ total portofolio value), the cost basis is the same fraction of acquisition costs. That is 10% of, let's say, 16000€. The cost basis is 1600€. Then, the taxable gain is 400€ euros. In order to be complete, the cost basis which was just taxed is to be deducted of subsequent operations. Let's say that, the next day, 3000€ are cashed out. The total acquisition costs would be now 14600€ (16000€-1600€). The new portofolio value maybe dropped from 18000€ to 15000€. The 3000€ sale price is 20% of total portofolio value. The cost basis 20% of 14600€, 2920€. The taxable gain is 80€. I really hope that this is correctly implemented and that only the guide is broken.

## Summary When syncing data to Xero, transactions labeled as "Loan Repayment" in Koinly are being posted as Debits to the "Realized P&L Account" (Account 265 in my setup). This incorrectly treats loan principal repayments as realized losses/expenses, causing massive discrepancies in the Profit & Loss report between Koinly and Xero. ## Impact In my specific case, this bug resulted in huge overstatement of losses in Xero. Koinly Tax Report: Shows correct Realized Gains/Losses. Xero P&L: Shows a massive loss because every loan repayment is treated as an expense. ## Current Behavior For a transaction labeled loan_repayment (e.g., withdrawing USD/Stablecoins to pay off a Nexo loan), Koinly generates the following Journal Entry: * Credit: Crypto Fiat Asset Account [100] (Correct: Asset decreases) * Debit: Crypto Realized P&L Account [265] ( INCORRECT : This records the repayment as a P&L Loss) ## Expected Behavior A Loan Repayment is a Balance Sheet transaction, not a P&L transaction. It should reduce a Liability. * Credit: Crypto Fiat Asset Account [100] * Debit: A designated Liability Account (e.g., "Crypto Loans"). ## Root Cause / Missing Configuration The current Xero Integration settings page ( https://app.koinly.io/p/settings/accounting ) does not provide a field to map "Loan Repayments" or "Liabilities". It only allows mapping: * Asset Accounts (Holdings, Fiat) * P&L / Income / Expense Accounts Because there is no "Liability Account" setting, the integration appears to default to the "Realized P&L Account" for the debit side of these withdrawals. ## My Configuration My settings at https://app.koinly.io/p/settings/accounting are configured as follows: * Crypto asset account: [127] Crypto Asset Account - Holdings * Fiat asset account (cash): [100] Crypto Fiat Asset Account * Realized P&L account: [265] Crypto Realized P&L Account * Fee account: [405] Crypto Fee Account * Income account: [271] Crypto Income Account * Expense account: [430] Crypto Expense Account * Gifts/donations/losses account: [266] Crypto Gifts/Donations/Losses Account ## Evidence / Example Transactions Here are specific examples of Manual Journals created by Koinly that demonstrate the error: Example 1: Journal ID: d4a7f100-3076-497a-aa60-16ef7710fc93 Date: 2025-11-05 Narration: Withdraw 49776.87 USD (net worth: 49776.87 USD, label: loan_repayment, desc: Crypto Repayment...) Account Code | Account Name | Debit | Credit | Note -------------|-------------------------------|------------|-----------|------------------------------ 100 | Crypto Fiat Asset Account | | 43,293.43 | Asset decreases (Correct) 265 | Crypto Realized P&L Account | 43,293.43 | | Loss Recorded (Incorrect) Example 2: Journal ID: 81508b7d-39b6-4777-925b-cd4050f89860 Date: 2025-11-04 Narration: Withdraw 34665.57 USD (net worth: 34665.57 USD, label: loan_repayment, desc: Crypto Repayment...) Account Code | Account Name | Debit | Credit | Note -------------|-------------------------------|------------|-----------|------------------------------ 100 | Crypto Fiat Asset Account | | 30,119.87 | Asset decreases (Correct) 265 | Crypto Realized P&L Account | 30,119.87 | | Loss Recorded (Incorrect) Example 3: Journal ID: 87951441-9a56-491f-954c-e5bc3fcc67d4 Date: 2025-11-11 Narration: Withdraw 33.51 USD (net worth: 33.51 USD, label: loan_repayment, desc: Crypto Repayment...) Account Code | Account Name | Debit | Credit | Note -------------|-------------------------------|------------|-----------|------------------------------ 100 | Crypto Fiat Asset Account | | 28.99 | Asset decreases (Correct) 265 | Crypto Realized P&L Account | 28.99 | | Loss Recorded (Incorrect) (Note: The amounts vary slightly from the narration due to cost basis calculations, but the accounting treatment is the issue). ## Suggested Fix Update the Xero Integration Settings: Add a new required field for "Liability Account" (or "Loan Account"). Update the Sync Logic: Ensure that any transaction with the label loan_repayment debits this new Liability Account instead of the Realized P&L Account.