LPOS
How to Lease your SWRM
Swarm ($SWRM) is an innovative blockchain platform designed to address the challenges of scalability, efficiency, and cost-effectiveness in the decentralized ecosystem.
Explanation of Leased Proof of Stake (LPoS) on the SWaRM Platform
Leased Proof of Stake (LPoS) is the consensus mechanism used by the SWaRM blockchain. It’s a variation of Proof of Stake (PoS) that allows users to “lease” their Native SWRM tokens to full nodes (validators) without transferring ownership. These leased tokens boost the node’s stake, increasing its chances of being selected to generate the next block and earn transaction fees. In return, node operators typically share a portion of these rewards with the users who leased their tokens to them. This system makes staking accessible to users who don’t want to run their own nodes, enhancing network participation and security.
Comparison to PoS and PoW
- LPoS vs. PoS: In traditional Proof of Stake, a user must hold and stake their tokens directly to participate in block validation, with their chances of being chosen proportional to their stake. LPoS builds on this by letting users lease their tokens to others, meaning even those with smaller holdings or no technical skills can contribute to the network and earn rewards. PoS typically requires running a node, while LPoS democratizes the process by outsourcing that responsibility.
- LPoS vs. PoW (Proof of Work): Proof of Work, used by Bitcoin, relies on computational power (mining) to validate transactions, consuming significant energy and requiring specialized hardware. LPoS, like PoS, uses token stakes instead, making it far more energy-efficient. Unlike PoW’s competitive mining, LPoS involves no hardware race—just token leasing and staking—reducing costs and environmental impact while maintaining security through economic incentives.
Process of Leasing on SWRM
- Initiate a Lease: Using a SWRM wallet (Our SWRM desktop wallet or SWRM Telegram wallet), a user creates a “Lease Transaction.” They specify the amount of WAVES to lease and the recipient node’s address. The tokens remain in the user’s wallet but are locked, meaning they can’t be spent or traded while leased.
- Node Activation: The leased SawRM are added to the node’s “generating balance” (effective stake), calculated as the lowest balance considering leasing over the last 1,000 blocks. A node needs at least 1,000 SWRM to generate blocks, so leasing helps smaller holders contribute to bigger nodes.
- Block Generation: The node uses its increased stake to compete for the right to generate the next block. If selected, it validates transactions, earns fees, and often shares rewards with leasers based on terms set by the node operator (not enforced by the protocol).
- Canceling the Lease: The user can stop leasing at any time by issuing a “Lease Cancel Transaction.” The tokens are unlocked instantly, though the node’s generating balance adjusts after 1,000 blocks, ensuring stability. Once canceled, the SWRM are fully spendable again.
This process keeps users in control of their funds, requires no technical expertise beyond the wallet interface, and aligns incentives to secure the SWaRM Network efficiently.
Reward Distribution in Leased Proof of Stake (LPoS) on the SWRM Platform
In the SWRM ecosystem, reward distribution under Leased Proof of Stake (LPoS) revolves around how nodes (block generators) share the benefits they earn with users who lease their SWRM tokens to them. Here’s how it works:
How Rewards Are Generated
- Block Generation: Nodes with a sufficient “generating balance” (at least 1,000 SWRM, including leased amounts) are eligible to create new blocks. The probability of a node being chosen to generate a block is proportional to its effective stake.
- Transaction Fees: When a node successfully generates a block, it collects 100% of the transaction fees from the transactions included in that block. Unlike some blockchains, SWaRM doesn’t have a fixed block reward in SWRM; the primary reward comes from these fees.
- Minimum Fee Sharing: Nodes keep all fees by default, but to incentivize leasing, many node operators voluntarily share a portion of these rewards with their leasers.
Reward Distribution Process
- Node Operator’s Discretion: The SWaRM protocol itself doesn’t enforce reward sharing between nodes and leasers. Instead, it’s up to each node operator to decide if, how much, and when to distribute rewards. This is typically advertised in advance (e.g., “80% of fees paid to leasers”) to attract users to lease to their node.
- Payout Mechanism: Node operators often distribute rewards manually or via automated scripts outside the core protocol (we recommend setting up the script for ease and community leaser’s trust). They calculate each leaser’s contribution to the node’s total generating balance (e.g., if you lease 1,000 SWRM to a node with 10,000 SWRM total, you’re 10% of the stake) and allocate a proportional share of the shared fees. Payments are often made in SWRM or other tokens like ENERGY or NOJO could be given as bonus or operating rewards respectively.
- Frequency: Payouts vary by node—some distribute daily, weekly, or monthly. Users need to check the node’s terms, often shared on forums, social media, or the node’s website (you can also check our Telegram “Node Leasing Options” channel).
- User Receipt: Rewards appear as incoming transactions in the leaser’s wallet. Since leasing doesn’t transfer ownership, users don’t need to “claim” rewards; they’re sent directly by the node operator.
Key Points
- Flexibility: Reward distribution isn’t hardcoded into the protocol, giving nodes freedom to set competitive terms. Some might offer higher percentages or additional incentives (e.g., tokens from SWaRM-based projects).
- Transparency: Users rely on the node’s reputation and track record, as there’s no on-chain guarantee of payouts. Trusted nodes publish payout histories to build credibility.
- No Penalty for Non-Payment: If a node doesn’t share rewards, leasers can simply cancel their lease and move to another node after the 1,000-block adjustment period.
Example
Suppose you lease 500 SWRM to a node with a total generating balance of 5,000 SWRM (10% contribution). The node earns 10 SWRM in fees over a week and promises to share 80% with leasers. The shared pool is 8 SWRM , so your share is 10% of that—0.8 SWRM—sent to your wallet at the node’s payout time.
In short, reward distribution in SWaRM LPoS depends on node operators’ policies, making it a trust-based but flexible system that aligns incentives between leasers and validators.
Details on Fee Calculation in Leased Proof of Stake (LPoS) on the SWaRM Platform
On the SWaRM blockchain, fee calculation is tied to transaction processing rather than block rewards, as there’s no fixed SWRM issuance per block like in some other systems. Fees are paid by users submitting transactions, collected by the block-generating node, and, in the context of LPoS, potentially shared with leasers. Here’s a detailed breakdown of how fees are calculated and managed:
Transaction Fees on Waves
- Fee Structure:
- Every transaction on SWaRM Network requires a fee, paid in SWRM (unless you have pre-purchased ENERGY Tokens for discounted transactions), to incentivize nodes to include it in a block.
- Fees are fixed based on the transaction type, not dynamically adjusted by network congestion (unlike Ethereum’s gas auctions). This predictability simplifies planning for users.
- Standard Fee Examples (as of early 2025, subject to governance changes):
- Transfer Transaction: 0.001 SWRM (basic token transfer).
- Lease Transaction: 0.001 SWRM (to start leasing).
- Lease Cancel Transaction: 0.001 SWRM (to stop leasing).
- Smart Contract Invocation: 0.005 SWRM or more, depending on complexity.
- Asset Issuance: 1 SWRM (for creating a new token).
- -** Creating a SWRM ID** .001 SWRM
These fees are set by the protocol but can be adjusted via community governance (e.g., through voting by nodes).
- Additional Fees for Custom Assets:
- If a transaction involves custom tokens (e.g., transferring a user-created asset), an extra 0.001 SWRM per asset might apply, depending on the transaction’s specifics.
Fee Collection by Nodes
- 100% to the Generator: The node that generates a block collects all fees from the transactions it includes. There’s no mandatory redistribution to the network or burning mechanism—everything goes to the block generator.
- No Minimum Fee Requirement: Nodes can theoretically include transactions with the minimum protocol-defined fees (e.g., 0.001 SWRM ), but in practice, they prioritize higher-fee transactions if block space is limited (though SWaRM’s high throughput of ~100 tx/s reduces congestion).
Fee Calculation in LPoS Context
While the protocol defines how fees are collected, the LPoS reward-sharing aspect (with leasers) involves a secondary calculation managed by node operators:
- Total Fees Earned: The node tallies all fees from transactions in the blocks it generates over a period (e.g., a day or week). For example, if a node generates 10 blocks with an average of 1 SWRM in fees per block, it earns 10 SWRM.
- Shared Reward Pool:
- The node operator decides what percentage of fees to share with leasers (e.g., 80%). Using the above example, 80% of 10 SWRM = 8 SWRM becomes the reward pool.
- This percentage isn’t enforced by the blockchain—it’s a voluntary commitment advertised by the node to attract leasers.
- Proportional Distribution:
- The reward pool is split among leasers based on their contribution to the node’s generating balance. The generating balance is the effective stake used for block generation, factoring in leased amounts (adjusted over the last 1,000 blocks).
- Formula: *Your Reward = (Your Leased SWRM/ Node’s Total Generating Balance) × Shared Reward Pool*
- Example: You lease 1,000 SWRM to a node with 10,000 SWRM total balance (10% contribution). If the shared pool is 8 SWRM, you get 10% of 8 = 0.8 SWRM.
- Payout Execution: The node operator sends these rewards as separate SWRM transactions to leasers’ wallets, incurring a small 0.001 SWRM fee per payout transaction. Sophisticated nodes might batch payouts to minimize costs.
Factors Influencing Fees and Rewards
- Network Activity: Higher transaction volume increases total fees, boosting node earnings and potential leaser rewards.
- Node Efficiency: A node’s uptime and ability to generate blocks (tied to its stake) determine how often it collects fees.
- Leasing Competition: Nodes with more leased SWRM have a higher generating balance, increasing their block generation odds and fee haul, but diluting individual leaser rewards unless fees scale proportionally.
- Operator Terms: Some nodes might deduct operational costs (e.g., server fees) before sharing, reducing the effective payout percentage.
Practical Example
- You lease 500 SWRM to a node with 5,000 SWRM total generating balance (10% stake).
- Over a week, the node generates 50 blocks, earning 0.5 SWRM per block = 25 SWRM total.
- The node shares 70% of fees (17.5 SWRM).
- Your share: (500 / 5,000) × 17.5 = 1.75 SWRM.
- The node sends you 1.75 SWRM, paying a 0.001 SWRM fee for the transfer.
In summary, fee calculation on Waves starts with fixed transaction fees set by the protocol, collected entirely by the block-generating node. In LPoS, the node operator then calculates and distributes a portion of these fees to leasers based on their leased stake, with the specifics varying by node policy. It’s a straightforward, predictable system with flexibility for operators to tailor reward strategies.
Fee Adjustment Mechanismson the SWaRM Platform
On the SWRM blockchain, transaction fees are primarily fixed by the protocol for each transaction type, but they aren’t static forever—adjustments can occur through decentralized governance mechanisms. Unlike some blockchains with dynamic fee markets (e.g., Ethereum), SWRM relies on a community-driven process involving nodes to tweak fees when needed. Here’s how fee adjustment works, particularly in the context of Leased Proof of Stake (LPoS):
Baseline Fee Structure
- Fees are predefined for each transaction type (e.g., 0.001 SWRM for a basic transfer, 1 SWRM for asset issuance). These are hardcoded into the protocol at launch or set via prior governance decisions.
- Nodes collect these fees when they generate blocks, and no protocol-level mechanism adjusts them in real-time based on network load—SWRM’s high throughput (~100 tx/s) reduces the need for such dynamics.
Governance-Based Fee Adjustment
SWaRM employs a decentralized governance model where fee adjustments are proposed, voted on, and implemented through the consensus of full nodes (block generators). This ties into the LPoS system, as nodes’ stakes (including leased SWRM) influence their voting power.
- Proposal Initiation:
- Any community member (e.g., developers, node operators, or users) can propose a fee change, typically via SWaRM forums, Discord, Telegram or GitHub. For example, they might suggest raising the transfer fee from 0.001 SWRM to 0.002 SWRM to increase node revenue or lowering it to boost adoption.
- Proposals often stem from observed network trends—like low node profitability or spam transactions clogging the chain.
- Node Voting:
- Full nodes (those with at least 1,000 SWRM in generating balance, including leased amounts) vote on the proposal. Voting power is proportional to their stake, so nodes with more leased SWRM have a bigger say.
- Voting happens on-chain via a special transaction type or off-chain through signed messages, depending on the implementation at the time (SWaRM governance can evolve, so specifics can shift).
- Consensus Threshold:
- A supermajority (e.g., 80% of voting nodes) is typically required to approve a change. This ensures broad agreement among stakeholders.
- The process might span a set period (e.g., 10,000 blocks, roughly a week) to allow all nodes to participate.
- Implementation:
- If approved, the fee adjustment is coded into a protocol update (soft or hard fork), deployed by the SWaRM team or community developers.
- Nodes must upgrade their software to the new version. Since Waves uses LPoS, non-upgraded nodes risk losing block generation rights, incentivizing compliance.
Historical Context and Exampleson other Waves Platforms
- Early Adjustments: Initially, fees like asset issuance (1 WAVES) were set high to prevent spam. Over time, community feedback led to discussions about lowering certain fees to encourage dApp development.
- Feature 15 (2019): An early governance vote adjusted smart contract fees, introducing a tiered structure (e.g., 0.005 WAVES base for script invocation). This showed how nodes could influence economics.
- No Dynamic Fees: Unlike PoW or gas-based systems, Waves hasn’t adopted real-time fee adjustments, relying instead on periodic governance to keep fees aligned with network goals.
Role of LPoS in Fee Adjustments
- Leasing Impact: Users leasing SWRM to nodes indirectly influence governance, as their tokens boost the voting power of their chosen node. A node with 50,000 leased SWRM has more sway than one with 5,000.
- Incentive Alignment: Nodes might push for higher fees to increase revenue (shared with leasers), while users might advocate lower fees for cheaper transactions. This tension shapes proposals.
Practical Example
- Scenario: Transaction volume spikes, but fees (0.001 SWRM per transfer) are too low, leaving nodes unprofitable.
- Proposal: A node operator suggests doubling the fee to 0.002 SWRM.
- Vote: Nodes with 70% of the total stake (e.g., 10 million SWRM out of 14 million staked) approve after a 10,000-block voting window.
- Update: A soft fork activates the new fee at block 2,500,000, and all nodes update to enforce it.
Limitations and Flexibility
- No Automation: Fee adjustments require human coordination, making them slower than dynamic systems but more deliberate.
- Community Dependence: Success hinges on active node participation—low turnout could stall changes.
- Future Potential: Proposals for on-chain fee markets or staking-weighted user voting can be possible but hasn’t been implemented.
In essence, SWaRM’s fee adjustment mechanism is a governance-driven process leveraging LPoS nodes’ stake-based voting. It balances predictability with adaptability, relying on the community—especially node operators bolstered by leasers—to align fees with network health and economic incentives.
Node Voting Process on the SWaRM Platform
The node voting process on the SWaRM blockchain is a key component of its decentralized governance, particularly within the Leased Proof of Stake (LPoS) framework. It allows full nodes—those responsible for block generation—to collectively decide on protocol changes, such as fee adjustments, feature activations, or other upgrades. Here’s a detailed explanation of how it works:
Overview
- Participants: Only full nodes with a generating balance of at least 1,000 SWRM (including leased amounts) can vote. This ensures that those with a stake in securing the network have a say.
- Purpose: Voting addresses proposals like fee changes, protocol upgrades, or parameter tweaks (e.g., block size or lease adjustment periods).
- Stake-Based Influence: A node’s voting power is proportional to its generating balance, tying the process directly to LPoS mechanics.
Steps in the Node Voting Process
- Proposal Submission:
- A change is proposed by a community member (e.g., a developer, node operator, or user) via informal channels like the SWaRM Network’s Discord, Telegram, or GitHub. For example: “Increase the transfer fee from 0.001 SWRM to 0.002 SWRM.”
- The proposal is refined into a concrete plan, often with input from the SWaRM team or core contributors, specifying the change and its rationale.
- Announcement and Discussion:
- The proposal is publicized to node operators and the broader community, typically with a discussion period (days or weeks) to gather feedback.
- Node operators assess how the change affects their revenue, leasers, and network health, influencing their stance.
- Voting Activation:
- On-Chain Voting: For some changes, voting is implemented via a special transaction type or protocol feature. Nodes signal their approval by including a vote in a block they generate or submitting a signed transaction.
- Off-Chain Voting: In earlier or less formalized cases, nodes might sign messages with their private keys (linked to their node address) and submit them to a designated coordinator (e.g., SWaRM team) or public tracker.
- A voting period is set, often tied to a block height range (e.g., 10,000 blocks, roughly one week), during which nodes cast their votes.
- Stake-Weighted Tally:
- Each node’s vote is weighted by its generating balance—the effective stake used for block generation, which includes both owned and leased SWRM.
- Example: A node with 10,000 SWRM (5,000 owned + 5,000 leased) has 10 times the voting power of a node with 1,000 SWRM.
- The total stake of all voting nodes is calculated, and votes are aggregated as a percentage of this total.
- Consensus Threshold:
- A supermajority is typically required for approval—often 80% or higher of the participating stake. This ensures broad agreement among nodes.
- If the threshold isn’t met (e.g., only 60% approve), the proposal fails unless revised and resubmitted.
- Implementation:
- Approved: The change is coded into a protocol update (soft or hard fork) by developers. A target activation block is set (e.g., block 2,500,000), giving nodes time to upgrade their software.
- Rejected: The status quo persists, and proponents may refine or abandon the idea.
- Nodes must adopt the new version to stay compatible; in LPoS, failing to upgrade risks losing block generation rights.
LPoS-Specific Dynamics
- Leasing Influence: Users who lease SWRM don’t vote directly—their tokens amplify the voting power of their chosen node. A node with many leasers can dominate decisions, aligning its interests with those contributors.
- Node Incentives: Nodes vote based on how changes affect their revenue (e.g., higher fees) or operational ease, balancing self-interest with network health to retain leasers.
- Decentralized Control: The larger the number of nodes the more voting reflects a distributed consensus rather than centralized authority.
Practical Example
- Proposal: Raise the smart contract invocation fee from 0.005 SWRM to 0.01 SWRM to deter spam.
- Voting Period: Blocks 2,490,000 to 2,500,000 (10,000 blocks).
- Participants: 50 nodes vote, with a total generating balance of 5 million SWRM.
- Node A: 50,000 WAVES (1% of total stake) votes “Yes.”
- Node B: 10,000 WAVES (0.2%) votes “No.”
- Aggregate: 4.2 million WAVES (84%) vote “Yes,” 0.8 million (16%) vote “No.”
- Outcome: The 80% threshold is met, so the fee increase activates at block 2,510,000 after a software update.
In summary, the node voting process on SWaRM is a stake-weighted, LPoS-driven mechanism where full nodes vote on protocol changes over a defined period, with outcomes enforced via software updates. It empowers those securing the network—bolstered by leasers—while requiring active participation to evolve the platform.
