On truncation of logs

Important information for users of Solana program logs data

Solana programs output logs as they run. You can obtain these from:

• Soldexer API’s logs data request
• other Soldexer API’s data requests as related data (e.g. when requesting transactions with "logs": true)
• from Solana RPCs via the logsSubscribe method

and other sources.

This data has a limitation that all users of this data must be aware of: logs are truncated if their total size per transaction exceeds 10kb.

Show details

More precisely, Solana runtime tracks the number of bytes as it outputs the log line by line. As soon as the number exceeds 10000 it outputs the final line reading Log truncated and stops the log writing operation. The only way to get around this limitation is to patch the runtime.

Here’s the code that does that in common Solana node implementations: modern, historical. Example of a transaction affected by the truncation (scroll to the very bottom in all explorers):

• SolanaBeach shows the raw program log and there’s a “Log truncated” line at the end.
• explorer.solana.com omits logs from instructions 15-18 in the parsed log.
• solana.fm shows logs of all instructions, strongly suggesting that they use a patched node for their data.

Soldexer uses data from a regular non-patched Solana node, so some logs in its dataset are truncated.

The practical consequence on this is that data consumers cannot be fully certain that they will always receive a log message whenever the relevant program code is executed. Whether or not this is acceptable depends on how the data is used.

To avoid having to deal with this issue we recommend using instructions and token balance updates in place of logs whenever possible. Anchor developed a special type of no-op instructions that can be used to mark execution events reliably, similar to how event logs work on EVM. If you program emits these, use them instead of execution logs.