Welcome to the weekly update on new software from the Paloma community of developers.
Pigeon Operator Keys testing on Paloma testnet revealed a newly discovered issue. Transactions were being stuck in the Paloma mempool for some validators. If you recall from our announcement of Pigeon Operator Keys here:
our goal with Pigeon Operator Keys are to allow validators to maximize message relay and attestation output by adding more signing keys to their pigeon module. While testing this new functionality, we noticed a number of transactions persisting in the CometBFT v0.37.2 mempool. We were unable to to determine why the transaction would not clear the mempool. We suspected that this was an artefact of the numerous validator keys signing, but determined it was a problem with CometBFT itself. According to ByteBandit:
Validators that use unjail scripts on Paloma will now find that this release will keep those validators jailed for increasingly longer periods of time. One of the blockers to effective message relay on Paloma has been the use of unjail scripts.
These scripts immediately bring a validator back to validating and securing the blockchain, but those pigeons that don’t have correct pigeon module configuration will then receive messages they fail to deliver. Failure to deliver a relay message means that the network value decreases as each failed message contributes to a higher unreliability standard that reduces the value of the GRAIN token for all other validators that have correct and working configurations. Waiting for failed messages to clear the message queue is slow and Paloma wants to be the fastest distributed-message relay system.
Thus, Paloma v10.0.1 introduces increasing validator jail times for validators that fail to fix or address pigeon configuration issues. The jail time increases for each attempt at 30 minutes + 20% of the time of the last jailing. Thus, if a validator that runs the unjail command, the first time, and is jailed again for a pigeon-specific performance reason, then that validator will need to cool-off for 30 minutes + 6 minutes. Once the cool-off period is complete, the validator may unjail and rejoin the network via unjail script or manual restart. In Paloma today, the unjail script reduces network effectiveness and reliability. This hurts all the other pigeons in the network and GRAIN token holders. Thus, this new feature:
In order to fix failing batches on Paloma Gravity bridge, Compass-EVM was given a new nonce for tracking called the
EventNonce
. This nonce is distinct from the
BatchNonce
as it adds more security against replay attacks. The last Compass-EVM included a temporary hardcoded nonce of 100000 that replaced the constructor input. In this release, we have a new ABI that supports the
event_id
as constructor input. This now requires a redeployment of Compass-EVM light client on all chains and an upgrade to pigeon to use the dynamic nonce. Pigeons will expect another upgrade to Pigeon and Compass-EVM once Paloma v10.0.1 deploys after governance.
Stay up to date and follow the Paloma public repositories and the commits of ongoing upgrades to Paloma Cosmos-SDK blockchain and the Pigeon relay module, here:
We are excited to make validators a top-tier citizen on the Paloma network with these improvements. The Gravity Bridge and Pigeon Operator Keys highlighted a number of fixes Paloma needs to be able to execute more onchain-bot transactions. These fixes also allow Paloma network to continue to grow its volume of transactions as it brings its long-awaited Pigeon Feed features onto the Paloma-Testnest-15.
Special thanks to the Vitwit team that continues to upgrade Paloma for Cosmos v0.50.0. Looking forward to testing modules on a new v0.50.0 branch of Paloma. COO! COO!
To learn more about Paloma, please visit
To follow the project on Github, please star the project
To participate in the community, please join the Paloma Discord: