Welcome to the weekly update on new software from the Paloma community of developers.
Paloma and Pigeon both upgraded to v1.10.0 with a number of enhancements for target chain communications. Today, we introduced Pigeon Operator Keys and their features that will allow validators to relay as many messages as possible to be included in a transaction block on the Paloma network, without account sequence mismatch errors.
In order to support multiple signing keys for Pigeons, we recently released a change for Paloma that introduced message metadata fields for all Paloma messages, allowing Pigeons to define signers other than the creator address.
This change includes:
NOTE: The new signing keys are completely optional
. In case there’s no change to the configuration, Pigeon will read the old existing
signature-key
field and use it for both the message creator and signer when injecting metadata. See below on how to enable support for multiple signing keys.
Going forward, we’ll be referring to the old
signing-key
as
validator-key
.
By default, Pigeon will use your validator key to sign any transactions sent to Paloma. In high throughput environments, this may lead to
account sequence mismatch
errors.
It’s possible to define more than one signing key to be used in rotation to combat this issue. In order to do so, you will need to create a number of new keys and register them with Pigeon like this:
After creating your signing keys, all you need to do is register them with Pigeon by adding the following to your pigeon config. Make sure to restart the service after making these changes.
Introducing Pigeon Operator Keys that brings a number of new concepts into the Paloma client that are required:
Using these new concepts, Paloma validators may add multiple signing keys for relaying and attesting to messages. Paloma now considers the metadata field contents when verifying transaction signatures. It does so by confirming that the transaction contains signatures from:
a) all signers of every message within the transaction
b) ensuring that the message creator is among the set of signers, or
at least
one of the signers of a message has active fee-grant from the message creator
This allows us to start using more than one key when signing transactions, as long as those keys are fee-granted from our validator account. It also sets the stage for multiple-signature transaction verification with each validator’s creator key.
There’s a hen & egg situation in case we’re currently onboarding a new chain on Paloma, as the chain status is not yet active, Validators without full support for the new chain will still be within the active validator set. Paloma v1.10.0 adds target chain awareness when filtering for viable message relayers, ensuring that validators with missing chain support for the required target chain are no longer considered for relay activities. This avoids having relay messages delayed in delivery.
This adds a new GRPC query to retrieve the last observed event nonce from Paloma. Pigeons will use this information in order to build their own state. This is an ongoing improvement in fixing the current paloma-testnet-15 Optimism bug that has a batch submitted infinitely due to inability of validators to verify the Event-Nonce due to the speed of the network.
The new Gravity Bridge Event-Nonce Observation requirement now requires an upgrade to Paloma’s EVM light client, Compass-EVM. Compass-EVM will now need to emit the Event-Nonce which will be queried by all the validators using Pigeon. Today, there two nonces used in Paloma’s cross-chain calls:
With the upgrade of the Compass-EVM, Paloma’s community will submit a new vote to upgrade the light client on testnet and mainnnet EVM target chains. This will then require a redeployment of all the Paloma and Curve bots which will complete the upgrade and prepare Gravity for further testing of Pigeon Feed features.
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:
Paloma Pigeon Operator Keys remove the dreaded
Account Sequence Mismatch
errors that block validators from using the same key to sign multiple messages in a Paloma block. Paloma’s vision is that validators are not limited in their ability to monetize their block space and their RPC endpoint investments. With Paloma Operator Keys, validators on Paloma may compete to monetize the entire stack. Maximum message relay throughput means Paloma becomes a core addition to the blockchain developers toolkit.
The Volume team continues to update Paloma’s Gravity Bridge to address batch event-nonce tracking and attestation. Compass-EVM upgrades and new votes will be coming this week to prepare for further Gravity upgrades.
We are excited for the next phase of Paloma.
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: