Welcome to the weekly update on new software design from the Paloma community of developers.
REMINDER WARNING:
The New Hatchling Paloma Network of
tumbler
(v1.15.0) and the Pigeon relay module are on v1.12.1 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
tumbler
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
tumbler
to experience weekly chain halts and chain restarts for upgrades. We also expect numerous undiscovered bugs and 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.
The Paloma Bridge Tax is a governance feature for all tokens on Paloma that allows any token to be demurred on transfer across the Paloma Gravity Bridge to any target chain. The demurrage rate is selected at governance and collected fees are burned on the Paloma side after the transfer to the target chain is complete. The Bridge Tax aims to achieve risk management for GRAIN token AMM pools on target chains. These pools at launch will have limited liquidity and may possibly be used mainly by Paloma validators to redeem GRAIN token relay rewards for target chain denominations. To ensure that Paloma validators are able to redeem GRAIN token rewards for target chain tokens with the most possible liquidity, the Paloma Bridge tax acts as risk management tool to increase validator reward value on the target chain.
The feature of the Paloma Bridge Tax are as follows:
The Paloma Bridge Tax charges a demurrage fee for a token transfer from Paloma to target chains. The Bridge Tax rate is defined by governance vote and we can set exceptions to tokens and addresses. The following are the requirements for the feature:
Paloma’s Gravity Bridge is new and undergoing continuous development, improvement and audits. Reviewing the history of bridge attacks, we notice that most bridges that were undermined lacked any way to limit the size of attacks and transactions that were allowed to cross the bridge. To increase security on this early Paloma Bridge, we propose another governance and security feature for bridging: The Paloma Bridge Daily Transfer Limit. The transfer limit aims to again protect validators by reducing the size of risk of unauthorized bridge tokens landing on target chains and impacting pools on which they depend for relay-fee refunds.
The design of the Paloma Bridge Daily Transfer Limits is as follows:
Add a limit to the amount of tokens transferred from Paloma, to any target chain, within a specified window, per token. This is defined by a new governance vote.
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.
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 back into the community pool onto Paloma and will have to be bridged back every
n
hours.
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 relayers who handle consensus messages such as the continuous valset updates that provide checkpoints of validator power on Compass-EVM.
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
Validators can use the following command`palomad tx treasury upsert-relayer-fee --help`` to access help on how to set their fees for relay activity.
This change adds a new constraint when handing out gravity batches to be relayed. They will now be withheld while valset updates are pending on the target chain, just like with SLC. Included is a more decentralised event bus system for decoupling systems. It’s currently very bare bone and as singleton hard to test, but if it grows, we will refactor into something more injectible,
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:
The Ice Pigeon breed is known and named for its “ice-blue” colour. It was first developed in the region from eastern Germany to western Poland, with most early breeding in Saxony and Silesia. Two or three distinct lineages, bred for centuries, were merged to form the modern-day Ice pigeon: one was light-winged with dark eyes, and another one or two had black wing markings and reddish eyes
Source:
This week completes work on Pigeon Feed Phase I. Relay fees are implemented with risk management and security for GRAINs and any other tokens launched on Paloma.
Pigeon Feed Phase II will cover the tracking of gas usage for pigeon reimbursement as well as implementation of the Compass v1.0.0 changes into Paloma and Pigeon. This week will launch testing of the Bridge Tax and the Bridge limits with test tokens as well as GRAINs. Once Phase II is complete, we will be able to launch GRAIN pools for Paloma validators on the various target chains.
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: