Welcome to the weekly update on new software design from the Paloma community of developers.
REMINDER WARNING:
The Hatchling Paloma Network of “Messenger” (v1.12.2) and the Pigeon relay module are on v1.10.3. Paloma is just over one year old and its Cosmwasm and EVM contracts are still unaudited and undergoing continuous upgrades on the protocol and its smart contracts. The GRAIN token is available on the Paloma mainnet but is not yet trading on exchanges. Although the flock is flying on the
messenger
mainnet, it is still subject to the continued development of Paloma’s cross-chain messaging system and the security guarantees offered by the GRAIN token. We expect “Messenger” to experience weekly chain halts and chain restarts for upgrades. We also expect numerous undiscovered vulnerabilities. No one on this project controls or influences the price of GRAINs. The community will strive to preserve the mainnet state, which includes balances, but considers this mainnet high-risk. Proceed with caution.
End-to-End Testing of the Cosmos SDK 0.50.0 is almost complete. The Vitwit team provided excellent script execution testing and updates to both Pigeon and Paloma. The Paloma team will now take over the final testing and upgrade to the latest version of Cosmos SDK 0.50.5. The next phase will require that Paloma’s protocol team backport the last release for attestation enforcement as well as upgrades to attestation checking. The runway view appears that Paloma will be ready for upgrade to both mainnet and testnest within the week.
We’re excited to bring a new Paloma to the flock which will bring Paloma up to speed and capacity of the leading blockchains in the Cosmos ecosystem. We’re optimistic that we’ll be ready for mainnest within the week.
We propose an upgrade to Compass-EVM architecture to allow for new functions for tracking relay activities by validators and their authenticated refund claims on each target chain. Below, we introduce the specification for the upgraded Compass-EVM for Pigeon Feed with the functions and their uses.
User
An entity on the Paloma network that can interact with the network using an address and sign transactions using a key pair. It could be a physical person, an automated script, or a smart contract execution.
Message
An arbitrary message that any user can send to any of Paloma’s supported target chains networks will be relayed by a Paloma validator, also known as a
relayer
.
Relayer
A
user
of the Paloma network who participates in consensus and provides his services as a relayer to the network receives a
fee
as a reward for the logic call work attempted.
Relayer fee
A reward fee is paid by the
user
when sending a message and reimbursed to the
relayer
at a later point. It is defined as a
fractional value
of the
estimated gas costs
of a transaction containing a message to be relayed.
Relayers
can set different fees on each target chain, for example:
To make a profit, the value must be greater than
1
. The fee is always paid in native chain currency on the target chain.
Community Fee
The community fee is set by governance on Paloma as a fraction of the
relayer_fee
. Users pay the community fee on top of the relayer fee when sending a message. The community fee is paid out to relayers who handle consensus messages like valset updates.
Security Fee
The security fee is set by governance on Paloma as a fraction of the
relayer_fee
. Users pay the security fee on top of the relayer fee when sending a message. The security fee is paid out to Volume.
Total fee
The total fee describes the total amount of fees a user will have to pay for sending a message. It is made up like this:
relayer_fee + community_fee + security_fee
Gas wallet
Any
user
who wants to relay a
message
must reimburse the
relayer
with a
fee
defined as a fraction of the estimated gas costs. The
user
pays this fee in native currency on the target chain.
This means the
user
will need to send their gas funds, on the target chain, into a
prepaid account
owned by Paloma’s
compass
, or directly to
compass
. The deposited amount is then used as payment for reimbursing relayers for any message sent by the
user
, as long as the balance can cover the minimum required costs.
This account (either owned by Compass or Compass itself) is called the
gas wallet
in the context of Pigeon Feed.
Assumptions and Requirements
Message lifecycle
Question:
How can we can avoid the second message by embedding the entire fee structure for the message into the payload?
Answer:
We populate the fee structure with plausible dummy values which will later be replaced with the actual fees to be moved. That way, payload size and execution flow should remain consistent between the estimate and the actual call, even though the given data for the fees will be different.
Therefore, the existing message lifecycle would be altered to include the fee structure as part of the payload, like this:
Stay up to date and follow the Paloma public repositories and the commits of ongoing upgrades to the Paloma Cosmos-SDK blockchain and the Pigeon relay module here:
AI-generated robo-pigeon seeing more green this week! Time to make the most of it before the market swings again. Start your bot today at
Welcome to Paloma message attestation enforcement and Cosmos SDK 0.50.0 integration testing. A new Paloma is ready to spread wings and a new fee market for validators, not yet seen in the Cosmos. We look forward to sharing the progress of testing the new Paloma as we prepare for public testnest and mainnest.
We continue to fly with the flock! 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: