A complete guide to staking and cross-chain trading DApp development
Stakingis the core economic mechanism of PoS blockchains, where users lock tokens to participate in network validation and earn yields.Cross-Chain TransactionsIt breaks down the barriers between different blockchains and realizes the seamless interoperability of assets and information. This article will systematically analyze how to develop a production-grade staking and cross-chain transaction DApp from smart contract design, protocol principles, to front-end integration.
What is Staking?
Staking refers to when users lock their crypto assets in a blockchain network or DeFi protocol in exchange for themCybersecurity contribution rewardsorAgreed revenue sharingbehavior. It serves as the economic foundation for the PoS (Proof-of-Stake) consensus mechanism.
The core value of staking
🔐 Cybersecurity
Validators stake assets as "margin" and are slashing for malicious behavior, and financial penalties ensure the honest operation of the network.
💰 Passive income
Stakers receive inflationary rewards and a share of transaction fees, with an annual percentage yield (APY) typically ranging from 3% to 20%.
🗳️ Governance rights
Staking tokens grant holders voting rights on on-chain governance and participate in important decisions such as protocol parameter adjustments and upgrade proposals.
🌊 Liquidity incentives
DeFi protocols channel liquidity through staking incentives, where users stake LP tokens or protocol tokens to earn additional rewards.
Mainstream public chain staking data
| Public chain | Pledge rate | Annualized return | Lock-up period | Minimum staking amount |
|---|---|---|---|---|
| Ethereum | ~27% | 3.5-4.5% | Instant exit via LST | 32 ETH (Native) |
| Solana | ~67% | 6-8% | ~2 days vesting period | No minimums |
| Cosmos | ~62% | 15-20% | 21-day vesting period | No minimums |
| Polkadot | ~53% | 12-15% | 28-day vesting period | Dynamic minimums |
| Avalanche | ~55% | 8-10% | 14-day vesting period | 25 AVAX |
Staking mode classification
| mode | mechanism | Advantages: | Disadvantages | Representative project |
|---|---|---|---|---|
| Native staking | Run validator nodes directly | Highest yield and complete autonomy | High threshold and operation and maintenance | Ethereum Solo Staking |
| Entrusted staking | Delegate tokens to validators | No O&M required, low threshold | Dependent on validator performance | Cosmos、Solana |
| Staking pools | Multiple aggregate assets are jointly pledged | Lower the minimum threshold and diversify risks | Trust pool operators | Rocket Pool |
| Liquid staking | Stake to get a Tradable Voucher (LST) | Maintain liquidity, composable DeFi | De-anchoring risk, contract risk | Lido(stETH) |
| Re-stake | Staked assets are re-pledged to protect other services | Maximize capital efficiency | Cascade liquidation risk | EigenLayer |
| DeFi staking | Stake tokens to earn protocol rewards | High APY and flexible combinations | Smart contract risks | Aave、Curve |
Staking system architecture
The system architecture of a production-grade staking DApp covers both the on-chain contract layer and the off-chain service layer:
Core data flow
- Users connect to their wallets through the DApp frontend and select the staking amount and validator
- The front-end calls the stake() method of the staking vault contract, and the user signs to confirm
- The contract locks user assets and mints an equivalent amount of LST tokens to return to users
- Off-chain services listen to staking events and update user status and global statistics
- The yield calculation service accumulates rewards in real time by block
- Users can request redemption through unstake() at any time to enter the unlock queue
Staking contract development
The following is a fully functional staking contract implementation, including staking, unlocking, reward distribution, and slashing mechanisms:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
/// @title StakingVault - 质押金库合约
/// @notice 支持灵活期限质押、动态APY和罚没机制
contract StakingVault is ReentrancyGuard, Ownable {
using SafeERC20 for IERC20;
IERC20 public stakingToken;
IERC20 public rewardToken;
uint256 public rewardPerSecond;
uint256 public lastUpdateTime;
uint256 public accRewardPerShare; // 每份累积奖励(精度1e18)
uint256 public totalStaked;
uint256 public unbondingPeriod = 7 days;
struct UserInfo {
uint256 amount; // 质押数量
uint256 rewardDebt; // 奖励债务(用于精确计算)
uint256 pendingRewards; // 待领取奖励
uint256 unstakeRequestTime;
uint256 unstakeAmount;
}
mapping(address => UserInfo) public userInfo;
event Staked(address indexed user, uint256 amount);
event UnstakeRequested(address indexed user, uint256 amount);
event Withdrawn(address indexed user, uint256 amount);
event RewardClaimed(address indexed user, uint256 amount);
event Slashed(address indexed user, uint256 amount, string reason);
constructor(address _stakingToken, address _rewardToken, uint256 _rewardPerSecond) {
stakingToken = IERC20(_stakingToken);
rewardToken = IERC20(_rewardToken);
rewardPerSecond = _rewardPerSecond;
lastUpdateTime = block.timestamp;
}
/// @notice 更新全局奖励累积
function updatePool() public {
if (block.timestamp <= lastUpdateTime || totalStaked == 0) {
lastUpdateTime = block.timestamp;
return;
}
uint256 elapsed = block.timestamp - lastUpdateTime;
uint256 reward = elapsed * rewardPerSecond;
accRewardPerShare += (reward * 1e18) / totalStaked;
lastUpdateTime = block.timestamp;
}
/// @notice 质押代币
function stake(uint256 amount) external nonReentrant {
require(amount > 0, "Cannot stake 0");
updatePool();
UserInfo storage user = userInfo[msg.sender];
// 结算已有奖励
if (user.amount > 0) {
uint256 pending = (user.amount * accRewardPerShare / 1e18) - user.rewardDebt;
user.pendingRewards += pending;
}
stakingToken.safeTransferFrom(msg.sender, address(this), amount);
user.amount += amount;
user.rewardDebt = user.amount * accRewardPerShare / 1e18;
totalStaked += amount;
emit Staked(msg.sender, amount);
}
/// @notice 请求解除质押(进入解锁期)
function requestUnstake(uint256 amount) external nonReentrant {
UserInfo storage user = userInfo[msg.sender];
require(user.amount >= amount, "Insufficient staked balance");
updatePool();
// 结算奖励
uint256 pending = (user.amount * accRewardPerShare / 1e18) - user.rewardDebt;
user.pendingRewards += pending;
user.amount -= amount;
user.rewardDebt = user.amount * accRewardPerShare / 1e18;
totalStaked -= amount;
user.unstakeAmount += amount;
user.unstakeRequestTime = block.timestamp;
emit UnstakeRequested(msg.sender, amount);
}
/// @notice 解锁期满后提取
function withdraw() external nonReentrant {
UserInfo storage user = userInfo[msg.sender];
require(user.unstakeAmount > 0, "No pending withdrawal");
require(
block.timestamp >= user.unstakeRequestTime + unbondingPeriod,
"Still in unbonding period"
);
uint256 amount = user.unstakeAmount;
user.unstakeAmount = 0;
stakingToken.safeTransfer(msg.sender, amount);
emit Withdrawn(msg.sender, amount);
}
/// @notice 领取奖励
function claimRewards() external nonReentrant {
updatePool();
UserInfo storage user = userInfo[msg.sender];
uint256 pending = (user.amount * accRewardPerShare / 1e18) - user.rewardDebt;
uint256 totalReward = user.pendingRewards + pending;
require(totalReward > 0, "No rewards");
user.pendingRewards = 0;
user.rewardDebt = user.amount * accRewardPerShare / 1e18;
rewardToken.safeTransfer(msg.sender, totalReward);
emit RewardClaimed(msg.sender, totalReward);
}
/// @notice 罚没机制(管理员调用)
function slash(address account, uint256 amount, string calldata reason) external onlyOwner {
UserInfo storage user = userInfo[account];
uint256 slashAmount = amount > user.amount ? user.amount : amount;
user.amount -= slashAmount;
totalStaked -= slashAmount;
// 罚没资产转入保险基金
stakingToken.safeTransfer(owner(), slashAmount);
emit Slashed(account, slashAmount, reason);
}
/// @notice 查看待领取奖励
function pendingReward(address account) external view returns (uint256) {
UserInfo storage user = userInfo[account];
uint256 _accRewardPerShare = accRewardPerShare;
if (block.timestamp > lastUpdateTime && totalStaked > 0) {
uint256 elapsed = block.timestamp - lastUpdateTime;
_accRewardPerShare += (elapsed * rewardPerSecond * 1e18) / totalStaked;
}
return user.pendingRewards + (user.amount * _accRewardPerShare / 1e18) - user.rewardDebt;
}
}
Contract design essentials
- Precision handling: Use the 1e18 precision factor to avoid the division cut-off loss
- Re-enter the protection: All funding operations are protected using ReentrancyGuard
- Unlock the queue:unbonding period to prevent instant arbitrage and flash loan attacks
- Reward debt model:rewardDebt ensures that new stakers do not receive historical rewards
- Upgradable design: The production environment should use UUPS Proxy to support contract upgrades
Liquid Staking
Liquid staking solves the problem of assets being locked and unusable in traditional staking. Users stake and earnLST(Liquid Staking Token)Voucher tokens that can be freely traded or participate in DeFi portfolios.
LST Economic Model
📈 Rebase mode
LST balance automatic growth reflects rewards (like stETH). Earn by holding without manual claims. Cons: Some DeFi protocols are not compatible.
💹 Exchange rate patterns
The number of LSTs remains unchanged, and the exchange rate continues to grow (e.g., rETH, cbETH). 1 rETH can be exchanged for more and more ETH over time. DeFi compatibility is better.
Exchange rate mode LST contract core
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
/// @title LiquidStakingToken - 流动性质押凭证
contract LiquidStakingToken is ERC20 {
uint256 public totalPooledAssets; // 池中总资产(含奖励)
uint256 public totalShares; // 总份额
constructor() ERC20("Staked ETH", "stETH") {}
/// @notice 质押 ETH 获得 LST 份额
function stake() external payable returns (uint256 shares) {
require(msg.value > 0, "Cannot stake 0");
if (totalShares == 0) {
shares = msg.value;
} else {
// 按当前汇率计算应得份额
shares = (msg.value * totalShares) / totalPooledAssets;
}
totalPooledAssets += msg.value;
totalShares += shares;
_mint(msg.sender, shares);
}
/// @notice 燃烧 LST 赎回底层资产
function unstake(uint256 shares) external returns (uint256 assets) {
require(shares > 0 && shares <= balanceOf(msg.sender), "Invalid shares");
// 按当前汇率计算应得资产
assets = (shares * totalPooledAssets) / totalShares;
totalPooledAssets -= assets;
totalShares -= shares;
_burn(msg.sender, shares);
// 实际项目中这里会进入提款队列
payable(msg.sender).transfer(assets);
}
/// @notice 获取当前汇率 (1 LST = ? ETH)
function exchangeRate() external view returns (uint256) {
if (totalShares == 0) return 1e18;
return (totalPooledAssets * 1e18) / totalShares;
}
/// @notice Oracle 报告验证者奖励(仅授权调用)
function reportRewards(uint256 rewardAmount) external {
// 奖励直接增加池中资产,汇率自动升高
totalPooledAssets += rewardAmount;
}
}
Combined applications of LSTs in DeFi
- Borrowing collateral: Stake stETH in Aave/Compound to lend stablecoins to achieve staking income + leverage
- Liquidity provision: Provide liquidity in the Curve stETH/ETH pool to earn trading fees
- Recurring staking: Staking → to obtain LST → collateral to lend ETH → and re-stake, amplifying the yield
- Income aggregation: Deposit LST into Yearn/Pendle to automatically optimize yield strategies
Restaking
Re-staking is one of the hottest DeFi innovations of 2024, pioneered by EigenLayer. Its core idea is:Let the staked ETH provide security for other protocols/services at the same timeto maximize capital efficiency.
Re-staking architecture
| Levels | Components | Function |
|---|---|---|
| Bottom floor | Ethereum PoS validator | Basic consensus security |
| Middle layer | Re-Staking Protocol (EigenLayer) | Staked asset sharing security |
| Application layer | AVS (Active Verification Service) | Oracle, DA layer, cross-chain bridges, etc |
The core logic of the re-pledge contract
// restaking/RestakingManager.sol
contract RestakingManager {
struct Operator {
address addr;
uint256 totalDelegated;
mapping(address => uint256) delegations;
address[] registeredAVS; // 注册的主动验证服务
}
mapping(address => Operator) public operators;
mapping(address => uint256) public withdrawalDelay; // AVS 指定的提款延迟
/// @notice 将 LST 委托给运营商
function delegateTo(address operator, uint256 amount) external {
// 转入 LST 代币
lstToken.transferFrom(msg.sender, address(this), amount);
operators[operator].delegations[msg.sender] += amount;
operators[operator].totalDelegated += amount;
}
/// @notice 运营商注册 AVS 服务
function registerAVS(address avs) external {
Operator storage op = operators[msg.sender];
op.registeredAVS.push(avs);
// AVS 可以对该运营商的质押资产执行 Slash
}
/// @notice AVS 触发罚没
function slashOperator(address operator, uint256 amount, bytes calldata proof) external {
require(isRegisteredAVS(msg.sender, operator), "Not registered AVS");
require(verifySlashingProof(proof), "Invalid proof");
Operator storage op = operators[operator];
op.totalDelegated -= amount;
// 按比例罚没委托者
}
}
While re-staking improves capital efficiency, it also carries the risk of cascading liquidation: if one AVS triggers a slash, it may affect all services that rely on the same staked asset. During development, it is necessary to design a reasonable penalty and risk isolation mechanism.
What is cross-chain trading?
Cross-chain transaction refers to thebetween different blockchain networksTechnology for transferring assets or passing on information. Each blockchain is an independent "data island", and cross-chain technology breaks through these islands and realizes multi-chain interoperability.
The core challenge of cross-chain
🔀 The state is not interoperable
Chain A cannot directly read the state of chain B. An external verification mechanism is required to prove that "a transaction did occur on another chain".
⏱️ Final difference
Different chains have different block times and confirmation mechanisms (Ethereum ~12s, Solana ~0.4s, Bitcoin ~10min), and cross-chain timings need to be handled.
🛡️ Security assumptions
The security of cross-chain bridges depends on the verification scheme - trusted relay, light node verification, or economic security model, each with its own attack surface.
💧 Liquidity fragmentation
The same asset has different "wrapped versions" on different chains (e.g., USDC.e vs native USDC), and liquidity is fragmented.
Cross-chain transaction types
| Type | Description | Typical scene |
|---|---|---|
| Assets cross-chain | Transfer tokens from chain A to chain B | ETH is bridged from Ethereum to Arbitrum |
| Messages cross-chain | Chain A sends arbitrary data to chain B | Governance voting results are synchronized across chains |
| Cross-chain calls | Chain A's contract triggers Chain B's contract execution | Cross-chain DeFi operation portfolio |
| Cross-chain swaps | Complete cross-chain + exchange in one step | Ethereum ETH → Solana SOL |
Cross-chain protocol principles
Different cross-chain solutions make different trade-offs between security, decentralization, and latency:
Mainstream cross-chain verification scheme
| Scheme | Verification method | Security | Delay | Representative project |
|---|---|---|---|---|
| Light node verification | The destination chain runs the light client of the source chain | Highest (equivalent to chain-of-origin security) | higher | IBC (Cosmos) |
| Optimistic validation | Assuming validity first, it can be disputed during the challenge period | High (Economic Security Game) | High (Waiting for a challenge period) | Optimistic Bridge |
| Zero-knowledge proofs | ZK proves that the source chain state transition is valid | Highest (mathematically proof) | Medium | zkBridge, Succinct |
| Multi-sign validators | N/M signatures confirm cross-chain messages | Medium (dependent on validator honesty) | low | Wormhole, Axelar |
| Decentralized oracles | Oracle network validation and relay | Medium | low | LayerZero, Chainlink CCIP |
LayerZero cross-chain message flow
- The source chain contract calls the send() method of the LayerZero Endpoint
- The oracle reads the source chain block header and commits it to the destination chain
- The Relayer submits the transaction proof to the destination chain
- The destination chain Endpoint verifies the validity of the block header + proof
- After verifying that the target link receives the contract's lzReceive()
- The target chain contract executes the corresponding business logic (minting tokens, executing operations, etc.)
Cross-chain bridge architecture
Cross-chain bridges are the core infrastructure for cross-chain transfers of assets, and the following are typical bridge architectures:
Lock-mint model vs liquidity pool model
🔒 Lock & Mint
The source chain locks the native asset → the destination chain mints the packaging asset. Reverse operation when redeeming. Simple and reliable, but there is a risk of unanchoring of packaged assets.
💧 Liquidity Pool
Both ends maintain liquidity pools and are released from the target chain pool when cross-chain. There is no need to mint wrapped tokens, but sufficient pool depth is required.
Cross-chain contract development
The following demonstration is a cross-chain token contract (OFT - Omnichain Fungible Token) based on the LayerZero V2 protocol:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import { OFT } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol";
import { SendParam, MessagingFee } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/interfaces/IOFT.sol";
/// @title CrossChainToken - 全链代币
/// @notice 部署在每条链上,支持跨链无缝转移
contract CrossChainToken is OFT {
constructor(
string memory _name,
string memory _symbol,
address _lzEndpoint,
address _owner
) OFT(_name, _symbol, _lzEndpoint, _owner) {
// 初始链上铸造初始供应
_mint(_owner, 1_000_000 * 1e18);
}
/// @notice 跨链转账
/// @param _dstEid 目标链的 LayerZero Endpoint ID
/// @param _to 目标链接收地址(bytes32格式)
/// @param _amount 转账数量
function bridge(
uint32 _dstEid,
bytes32 _to,
uint256 _amount
) external payable {
SendParam memory sendParam = SendParam({
dstEid: _dstEid,
to: _to,
amountLD: _amount,
minAmountLD: _amount * 99 / 100, // 允许 1% 滑点
extraOptions: bytes(""),
composeMsg: bytes(""),
oftCmd: bytes("")
});
MessagingFee memory fee = _quote(sendParam, false);
require(msg.value >= fee.nativeFee, "Insufficient fee");
_send(sendParam, fee, msg.sender);
}
/// @notice 预估跨链费用
function quoteBridge(
uint32 _dstEid,
bytes32 _to,
uint256 _amount
) external view returns (uint256 nativeFee) {
SendParam memory sendParam = SendParam({
dstEid: _dstEid,
to: _to,
amountLD: _amount,
minAmountLD: _amount * 99 / 100,
extraOptions: bytes(""),
composeMsg: bytes(""),
oftCmd: bytes("")
});
MessagingFee memory fee = _quote(sendParam, false);
return fee.nativeFee;
}
}
Cross-chain swap contract (source chain)
// crosschain/SwapBridge.sol - 跨链兑换
contract CrossChainSwap {
ILayerZeroEndpoint public lzEndpoint;
mapping(uint32 => address) public peerContracts; // 对端合约
struct SwapOrder {
address sender;
address tokenIn;
uint256 amountIn;
address tokenOut; // 目标链上期望收到的代币
uint256 minAmountOut;
uint32 dstEid;
}
/// @notice 发起跨链Swap
function initiateSwap(SwapOrder calldata order) external payable {
// 1. 锁定源链资产
IERC20(order.tokenIn).transferFrom(msg.sender, address(this), order.amountIn);
// 2. 编码跨链消息
bytes memory payload = abi.encode(
order.sender,
order.tokenOut,
order.minAmountOut
);
// 3. 发送跨链消息到目标链
lzEndpoint.send{value: msg.value}(
order.dstEid,
abi.encodePacked(peerContracts[order.dstEid]),
payload,
payable(msg.sender),
address(0),
bytes("")
);
}
/// @notice 目标链接收并执行Swap
function _lzReceive(bytes calldata payload) internal {
(address recipient, address tokenOut, uint256 minAmount) =
abi.decode(payload, (address, address, uint256));
// 从流动性池中兑换并转给用户
uint256 amountOut = _executeSwap(tokenOut, minAmount);
IERC20(tokenOut).transfer(recipient, amountOut);
}
}
Cross-chain security
Cross-chain bridges are the hardest hit by hacker attacks - many hundreds of millions of losses have occurred on bridge protocols in history. Secure design is a top priority for cross-chain DApps.
Historical major security incidents
| event | loss | Root cause | Lesson |
|---|---|---|---|
| Ronin Bridge (2022) | $625M | 5/9 Validator private key compromised | The number of multiple signatures is not dispersed enough |
| Wormhole (2022) | $320M | Signature verification bypasses vulnerabilities | Insufficient contract upgrade audits |
| Nomad (2022) | 90M | Merkle Root initialization error | The initialization parameters need to be strictly verified |
| Harmony Bridge (2022) | 00M | 2/5 The threshold for multiple signatures is too low | The multi-signature ratio requires ≥ 2/3 |
Cross-chain security best practices
🔐 Multi-layer verification
Does not rely on a single source of validation. The combination of oracle + repeater + application-level security module will not affect the overall security if either layer is breached.
⏸️ Rate limiting
Set the maximum bridge amount per transaction/day. Overrun transactions trigger manual review to buy response time for detecting attacks.
🚨 Emergency suspension
Multi-signature governance can urgently suspend bridging. With on-chain monitoring (such as Forta), abnormal transactions are automatically suspended.
🧮 ZK proof
Verify source chain state with zero-knowledge proofs, reducing trust assumptions to the mathematical level, eliminating the human element.
- Message replay protection: Each message is bound to a unique nonce, and the destination chain records the processed noncees to prevent replay
- Final waiting: Source chain transactions must reach a sufficient number of confirmations before relaying to prevent chain restructuring from leading to double-spending
- Amount verification: The target chain verifies that the minting/release amount is strictly consistent with the source chain locked/burned amount
- Regular audits: Contract changes must be audited and deployed by Trail of Bits, OpenZeppelin, and other institutions
DApp front-end integration
The frontend of staking and cross-chain DApps needs to handle complex interactions such as multi-chain connections, transaction signing, and state tracking:
Core front-end interaction flow
// frontend/hooks/useStaking.ts - React 质押 Hook
import { useWriteContract, useReadContract, useWaitForTransaction } from 'wagmi';
import { parseEther, formatEther } from 'viem';
import { stakingVaultABI } from '../abis/StakingVault';
export function useStaking(vaultAddress: `0x${string}`) {
const { writeContract, data: hash } = useWriteContract();
const { isLoading } = useWaitForTransaction({ hash });
// 读取用户质押信息
const { data: userInfo } = useReadContract({
address: vaultAddress,
abi: stakingVaultABI,
functionName: 'userInfo',
args: [userAddress],
});
// 读取待领取奖励
const { data: pendingReward } = useReadContract({
address: vaultAddress,
abi: stakingVaultABI,
functionName: 'pendingReward',
args: [userAddress],
});
// 执行质押
const stake = async (amount: string) => {
await writeContract({
address: vaultAddress,
abi: stakingVaultABI,
functionName: 'stake',
args: [parseEther(amount)],
});
};
// 请求解除质押
const requestUnstake = async (amount: string) => {
await writeContract({
address: vaultAddress,
abi: stakingVaultABI,
functionName: 'requestUnstake',
args: [parseEther(amount)],
});
};
// 领取奖励
const claimRewards = async () => {
await writeContract({
address: vaultAddress,
abi: stakingVaultABI,
functionName: 'claimRewards',
});
};
return { stake, requestUnstake, claimRewards, userInfo, pendingReward, isLoading };
}
// frontend/hooks/useCrossChainBridge.ts - 跨链桥 Hook
export function useBridge(bridgeAddress: `0x${string}`) {
const { switchChain } = useSwitchChain();
const bridge = async (params: {
dstChainId: number;
token: string;
amount: string;
recipient: string;
}) => {
// 1. 预估跨链费用
const fee = await readContract({
address: bridgeAddress,
abi: bridgeABI,
functionName: 'quoteBridge',
args: [params.dstChainId, params.recipient, parseEther(params.amount)],
});
// 2. 授权代币
await writeContract({
address: params.token,
abi: erc20ABI,
functionName: 'approve',
args: [bridgeAddress, parseEther(params.amount)],
});
// 3. 发起跨链
await writeContract({
address: bridgeAddress,
abi: bridgeABI,
functionName: 'bridge',
args: [params.dstChainId, params.recipient, parseEther(params.amount)],
value: fee,
});
};
return { bridge };
}
Multi-chain wallet connection
- wagmi + RainbowKit: The EVM ecosystem is the first choice, supporting MetaMask, WalletConnect, and Coinbase Wallet
- @solana/wallet-adapter: Solana ecosystem wallet integration
- CosmosKit: Cosmos ecosystem Keplr wallet connection
- Cross-chain state tracking: Track cross-chain message status through the LayerZero Scan / Wormhole Explorer API
Recommended technology stack
| module | Technical selection | Description |
|---|---|---|
| Smart Contract | Solidity + Foundry + OpenZeppelin | Test quickly, enrich templates |
| Cross-chain protocol | LayerZero V2 / Chainlink CCIP | Mature ecology and multi-chain coverage |
| LST standard | ERC-4626 Tokenized Vault | Standardized income vault interface |
| Front-end frame | Next.js + wagmi + viem | SSR + Type-Safe Contract Interaction |
| Multi-chain connection | RainbowKit / ConnectKit | Premium UX wallet connectivity components |
| Data indexing | The Graph / Ponder | Real-time index queries for on-chain events |
| Backend services | Node.js / Go + Redis + PostgreSQL | Status tracking, revenue calculation |
| Monitoring | Forta + Tenderly + OpenZeppelin Defender | Security monitoring and automated operation and maintenance |
| Testnet | Sepolia + Arbitrum Sepolia + Base Sepolia | Multi-chain testing environment |
| Audit tools | Slither + Mythril + Echidna | Static analysis + fuzz testing |
Development process
Based on the NovaLinkR team's experience in staking and cross-chain project delivery, the following development processes are recommended:
Requirements analysis and protocol selection
Determine the target chain (EVM/non-EVM), staking model (native/LST/DeFi), cross-chain protocol (LayerZero/CCIP/self-built), and token economic model design.
Smart contract development and testing
Write staking vaults, LST tokens, cross-chain adapter contracts. Foundry 100% coverage test, Invariant test verifies the safety of funds.
Cross-chain integration and multi-chain deployment
Configure LayerZero/CCIP endpoints, set peer contract trust relationships, and end-to-end verification on the multi-chain testnet.
Front-end DApp development
Staking panel, yield dashboard, cross-chain bridge interface, transaction status tracking. Responsive design for desktop and mobile devices.
Security audit and formal verification
Third-party audit (CertiK/Trail of Bits), Certora formal verification, Bug Bounty launch (Immunefi).
Mainnet deployment and operation
Grayscale is launched (full limit →), security monitoring configuration, TVL growth strategy, partner integration, and continuous iteration.
The NovaLinkR team has successfully delivered multiple staking protocols and cross-chain bridge projects, covering LST token design, multi-chain contract deployment, and full-stack DApp development.Contact us todayGet free technical consultation and customized solutions.