SatoshiFi.
Bitcoin without intermediaries.

Introduction and project overview

SatoshiFi is a system of decentralized mining pools and BTC federations built on smart contracts deployed to Ethereum (or compatible EVM networks). The project combines two layers: local mining pools (MiningPoolDAO) governed by a DAO of operators and miners, and global coordination through MultiPoolDAO for each native network (Bitcoin, Dogecoin, Bitcoin Cash, Litecoin).

All critical processes — reward distribution, UTXO verification, signature formation — happen on-chain. No single point of failure, no custodial model in the traditional sense: native BTC remains on federation addresses secured by threshold signatures, while ERC-20 wrappers (mpToken and sToken) circulate freely in DeFi.

What the protocol delivers

Target audience

• Miners — for pool integration, share submission, and receiving mpToken/sToken with the option of direct redemption into native networks or use in DeFi.
• Pool operators — for configuring and managing DAO pools, participating as solvers and oracles.
• Institutional investors and family offices — for participating in the custodian DAO and in Solver/Curator capital streams.
• Developers — for building custom calculators through the IDistributionScheme interface.

System architecture

The system is built as a modular stack of contracts on Ethereum. Each layer addresses a specific concern and exposes an interface to the next. Separating local pool management (MiningPoolDAO) from global coordination (MultiPoolDAO) is the principal architectural decision that allows the system to scale across networks and pools.

Architecture layers

Key components

Data flow: Reward → mpToken → sToken → redemption

1. Bitcoin reward transaction A miner finds a block; a coinbase transaction is formed in the native network.
2. SPV maturity + merkle proof SimpleSPVContract verifies block maturity (≥ 100 confirmations) and Merkle inclusion of the transaction.
3. Pool registers UTXO MiningPoolDAO records the confirmed coinbase UTXO in its internal registry.
4. Distribute reward The calculator (PPS/FPPS/PPLNS/Score) computes worker shares. PoolMpToken.mint issues mpTokens.
5. Deposit mpToken to MultiPool The miner calls depositMpToken. SafeERC20 transfers tokens, with an optional wrap fee withheld.
6. Share token minted sTokens (SBTC/SDOGE/SBCH/SLTC) are minted; the per-pool user balance is updated.
7. Request withdrawal Withdrawal request: balance check, pending lock creation, operation hash derivation.
8. FROST approval Threshold signature from federation participants. For confederations, additional custodian threshold is required.
9. BTC redemption broadcast constructRedemptionTx builds a Bitcoin transaction; an off-chain MPC signer broadcasts it on the native network.
10. verifyBurnViaSPV Raw txid/source/output checks. Escrow is burned, reserved/spent UTXO accounting updated, request closed.

Smart contract layer

All contracts are written in Solidity ^0.8.19 using OpenZeppelin libraries (AccessControl, ReentrancyGuard, Pausable, SafeERC20). Below is a summary of the key contracts and their public APIs.

MiningPoolDAO

Local pool management: share intake, SPV block verification, reward distribution through calculators, mpToken issuance, and interaction with MultiPoolDAO for sToken conversion.

Key data structures:

• UTXO — txId, vout, amount, spent
• LockedTokens — networkId, owner, amount, powScript, txId, createdAt, deadline, status
• PoolInfo — poolId, networkId, payoutScript, active
• NetworkConfig — active, spv, sToken
• Backing — totalReceived, reserved, available

Primary functions:

initialize(address frostAddress, bytes groupPub, uint64 redemptionTimeout, address slashRecv)
setNetwork(uint8 networkId, address spvAddr, address sToken, bool active)
registerPool(bytes32 poolId, uint8 networkId, bytes payoutScript, address operator)
receiveReward(bytes32 poolId, bytes blockHeaderRaw, bytes txRaw, uint32 vout,
              bytes32[] merkleProof, uint8[] directions)
mintSTokenWithProof(bytes32 poolId, bytes blockHeaderRaw, bytes txRaw, uint32 vout,
                    bytes32[] merkleProof, uint8[] directions, uint256 amount, address recipient)
burnAndRedeem(uint8 networkId, uint256 amount, bytes powScript)
withdrawFees(uint8 networkId, address to, uint256 amount)

SimpleSPVContract

Stores block headers, tracks the mainchain by cumulative work, and verifies transaction inclusion through Merkle proofs. It also owns the pool UTXO registry. Admin functions are restricted to spvAdmin; test helpers can be permanently disabled via disableTestHelpers().

function addBlockHeader(bytes calldata rawHeader) public
function disableTestHelpers() external
function setPoolContract(address poolContract) external
function transferSPVAdmin(address newAdmin) external
function isMature(bytes32 blockHash) external view returns (bool)
function isMatureWithDepth(bytes32 blockHash, uint32 confirmationDepth) external view returns (bool)
function checkTxInclusion(bytes32 blockHash, bytes32 txid, bytes32[] calldata siblings, uint256 index)
    external view returns (bool)
function registerPoolUTXO(bytes32 txid, uint32 vout) external
function markPoolUTXOSpent(bytes32 txid, uint32 vout) external

SimpleFROSTMultisig

The authorization adapter for federation and confederation contracts. It operates in two modes: legacy counter mode (for compatibility and tests) and strict cryptographic mode (production). Once cryptographic FROST is bootstrapped, legacy counter approvals are permanently disabled.

function bootstrapCryptographicFROST(
    address verifier,
    bytes calldata groupPubkey,
    string calldata signatureType
) external

function approveOperationWithAggregateSignature(
    bytes32 operationHash,
    address target,
    bytes calldata aggregateSignature
) external

Target-bound operation hash

All privileged operations use target-bound hashes that include the domain, chainid, FROST contract address, target contract, function selector, parameter hash, and nonce.

function hashOperation(
    address target,
    bytes4 selector,
    bytes32 paramsHash,
    uint256 nonce
) external view returns (bytes32)

Target contracts expose helper functions: getAddPoolOperationHash, getSetFeeManagerOperationHash, getProcessWithdrawalOperationHash, and others. Callers should always use these helpers instead of constructing hashes by hand.

User scenarios

The system supports six primary interaction scenarios for two base roles: miners and pool operators. Additional flows cover oracles and FROST participants.

Scenario 1 — Mining → mpToken

1. The miner produces a block and receives the coinbase UTXO.
2. Share data is sent via Stratum to StratumDataAggregator.
3. The aggregator forwards data to MiningPoolDAO.
4. SPVContract verifies Merkle proof and block maturity (≥ 100 confirmations).
5. A calculator from CalculatorRegistry distributes shares across WorkerData/MemberData.
6. PoolMpToken.mint issues mpToken to recipients.

Scenario 2 — Convert mpToken → sToken

The miner can keep mpToken in an ERC-20 wallet for unrestricted transfer, use them in DeFi, or convert them to sToken via MultiPoolDAO.depositMpToken. Conversion involves a re-verification of the underlying UTXO through SPV and burns the mpToken.

Scenario 3 — Redeem sToken to native assets

1. The user calls burnAndRedeem(networkId, amount, powScript).
2. PoolSToken.burnFrom burns the sTokens and moves mpToken into escrow.
3. An operation hash is built; a FROST session is initiated.
4. t-of-n federation participants (plus custodian threshold for confederations) approve the operation.
5. constructRedemptionTx builds a BTC transaction with explicit miner fee and an RBF-compatible sequence.
6. An off-chain MPC signer broadcasts the transaction on the native network.
7. verifyBurnViaSPV confirms inclusion; escrow is burned and reserves settled.

Scenario 4 — Pool setup by an operator

The operator calls MiningPoolFactory.createPool and receives a deployed clone of MiningPoolDAO together with a mpToken. The pool is then registered in MultiPoolDAO, a calculator is selected through CalculatorRegistry, and a payout policy is configured.

Scenarios 5–6 — Stratum oracles and FROST

Oracles register with StratumOracleRegistry, receive ORACLE_ROLE, and submit data validated by StratumDataValidator. FROST sessions are created for each redemption operation and finalized with an aggregated Schnorr signature, verified through FROSTVerifier.

Tokenomics and distribution models

Token economics revolve around two token types: mpToken (Mining Pool Token) and sToken (SBTC, SDOGE, SBCH, SLTC). Both are ERC-20 and both are backed 1:1 by their native assets.

mpToken — local pool token

Issued by PoolMpToken for a specific pool. It is a wrapped version of the native asset (1 mpBTC = 1 BTC). It is minted after SPV verification of the coinbase and execution of the calculator. mpToken can be held in any ERC-20 wallet, transferred between addresses, used in DeFi, or burned during conversion to sToken.

sToken — global network token

Issued by MultiPoolDAO after a second UTXO verification. SBTC for BTC, SDOGE for Dogecoin, and so on. Used for redemption to native assets through FROST or for DeFi. Backed by pool reserves (Backing.available).

Reward distribution models

Economic incentives

• Miners — instant rewards in 1:1-backed mpToken; model choice (PPS, FPPS, PPLNS, Score) shapes the payout profile.
• Operators — fees in sToken, DAO governance through NFT/SBT.
• Oracles — staking and slashing in StratumDataValidator enforce honest reporting.
• Safety — Backing reserves guarantee 1:1 collateralization, defaultRedemptionTimeout bounds large withdrawals.

FROST, DKG, and BIP340

FROST (Flexible Round-Optimized Schnorr Threshold Signatures) is the foundation of the federation's cryptographic guarantees. The private key never exists in whole form: each participant holds a share, and signing requires collecting a threshold (t-of-n) of partial signatures.

Why FROST

• Decentralization — signing without a trusted coordinator; responsibility is split across participants.
• Efficiency — fewer communication rounds than MuSig2; optimized for Schnorr.
• Security — with t > n/2 it tolerates minority compromise; VSS protects against rogue-key attacks.
• BIP340 compatibility — Schnorr signatures are natively valid in Bitcoin Taproot.

Distributed Key Generation (DKG)

DKG in SatoshiFi does not generate secrets on-chain. The DKGCoordinator contract coordinates the protocol: collecting VSS commitments, share hashes, public key shares, and threshold attestations for the final group public key.

1. VSS commitment hashes — participants publish commitments.
2. Encrypted share hashes — per-recipient encrypted shares.
3. Public key shares submission — per-share public keys.
4. Group public key approval — threshold attestations for the final key.
5. completeDKG — finalization after secp256k1 validation and even-Y check.
6. deployFederationWithCryptographicFROST — deployment with immediate bootstrap.

The safe path is finalizeDKG(uint256, bytes calldata groupPubkey) with externally generated group key material. The argumentless finalizeDKG(uint256) is deliberately disabled with an explicit revert because it generated secrets on-chain.

FROSTVerifier — supported formats

Group public key:

• 64 bytes — abi.encodePacked(uint256 pubX, uint256 pubY)
• 33 bytes — SEC compressed key
• 32 bytes — BIP340 x-only key, lifted to even Y

Signatures:

• Schnorr/BIP340 — 64 bytes (Rx, z) with even-Y lift, or 96 bytes (Rx, Ry, z)
• ECDSA — 65 bytes (r, s, v)

Schnorr verification rejects odd-Y group keys and odd-Y R points for the BIP340 path.

Strict cryptographic mode vs. legacy counter

After bootstrapCryptographicFROST or configureCryptographicFROST is called, the counterApprovalsEnabled flag becomes permanently false. All subsequent approvals must go through approveOperationWithAggregateSignature with a real aggregate signature, checked by cryptographicVerifier.verify.

Legacy counter mode remains in the contracts for tests and backward compatibility but is not the production security boundary. Production deployments always use the strict path deployFederationWithCryptographicFROST(...) or deployConfederationWithCryptographicFROST(...).

SPV verification and UTXO handling

Simplified Payment Verification is a deliberate trade-off between completeness and efficiency. SatoshiFi does not run a full Bitcoin node on-chain; instead it verifies transaction inclusion through block headers and Merkle paths.

SimpleSPVContract: what gets verified

• 80-byte block header shape.
• Existence of the previous block in the chain.
• Target derived from bits; block hash ≤ target.
• Difficulty bits preserved on non-retarget blocks.
• Cumulative work used to track the mainchain.

Maturity and reorgs

The standard maturity depth is 100 confirmations (Bitcoin coinbase maturity). In production this parameter should be raised above the demo constant. isMatureWithDepth allows the depth to be set explicitly. Chain reorganizations of up to 10 blocks (BTC) are supported; Dogecoin uses a chain-length heuristic due to its high block rate.

Pool UTXO registry

The SPV contract also owns the pool UTXO registry. Pool contracts are registered through setPoolContract (only spvAdmin) and then register their UTXOs via registerPoolUTXO(txid, vout). Test helpers (addBlockWithHash, setBlockMerkleRoot) must be permanently disabled in production through disableTestHelpers().

Reserve accounting in SimpleMiningPoolWithCalculator

• Available / reserved / spent BTC reserve.
• UTXO reserved/spent state.
• Explicit miner fee in constructed BTC transactions.
• RBF-compatible sequence policy.
• SIGHASH_ALL | SIGHASH_ANYONECANPAY for fee bumping.

Finality per network

Federation and confederation

A federation is a group of participants that jointly hold shares of the BTC address key through DKG. A confederation extends a federation with institutional custodians: critical operations require both a FROST threshold and a custodian threshold.

FederationFactory — deployment

The strict production path deployFederationWithCryptographicFROST(...) atomically deploys and initializes:

• SimpleFROSTMultisig with cryptographic FROST already bootstrapped
• SimpleMultiPool for MP-token aggregation
• MultiPoolShareToken (the federation's sToken)
• Optional fee system through deployer wiring

ConfederationFactory — adds custodian validator

deployConfederationWithCryptographicFROST(...) additionally deploys CustodianValidator. All MultiPool operations in a confederation require two independent approvals: a FROST threshold for the target-bound operation hash and a custodian threshold for the same hash. The custodian set is managed inside CustodianValidator, not only in a governance wrapper.

MultiPool accounting

SimpleMultiPool and ConfederationMultiPool track per-user and per-MP-token balances:

• userPoolBalances[user][mpToken]
• pendingUserPoolShares[user][mpToken]
• PoolInfo.exists — preserves accounting on reactivation

Withdrawals lock shares in pending accounting first and burn them only when the withdrawal is processed. A user can cancel after WITHDRAWAL_CANCEL_DELAY, and an approved reject path can release pending shares. This model prevents the use of S-tokens from one MP pool to withdraw from another MP pool.

Federation addresses and key rotation

Addresses are generated through DKG in FROSTCoordinator. The public key (xpub) is created on-chain; derivation follows BIP-32 (HD wallets) adapted for P2WSH (BTC, BCH, LTC) or Scrypt-compatible addresses (DOGE). The address list is stored in BridgeInbox and exposed via AddressGenerated events.

Key rotation is initiated by DAO vote or on schedule (≈ 6 months, ≈ 262,800 blocks for BTC). A new DKG runs, old keys are invalidated, and funds are moved to the new address through a multisig transaction. The rotation is confirmed on-chain through SPV.

Proof-of-Reserves

• Public UTXO list — in BridgeInbox.federationAddresses, with UTXOUpdated events.
• Mint/burn reconciliation — TokenMinted on UTXO receipt, TokenBurned on redemption. The invariant: totalSupply(sToken) ≤ totalUTXO.
• Merkle proofs — relayers submit proofs weekly; the contract verifies them on-chain.
• External audit — independent verification through the native network explorer cross-referenced against on-chain BridgeInbox data.

Custodians, deposits, and slashing

A custodian is a trusted participant from MultiPoolDAO who holds a share of the cryptographic key through FROST and guarantees that every pool member can withdraw their share independently. Misbehavior is punished by slashing the custodian's deposit.

Pure MiningPoolDAO vs. pool with custodian

Slashing-deposit mechanics

The custodian posts a deposit in the network's native currency (ETH, BTC, USDC) or in a dedicated DAO token. The deposit is locked for the entire participation period and slashed on proven violations: signing an invalid request, refusing to sign a valid request, or colluding with other participants.

Fee and slashing formulas

Optional fee tied to deposit size (incentivizes larger deposits):

f = k / (d + c) × r

k — risk constant (e.g., 1e18)
d — custodian deposit
c — minimum offset (e.g., 1e15)
r — total pool reward for the period

Alternative — fixed custodian percentage:

f = p × r

p — agreed percentage (e.g., 0.005 for 0.5%)
r — total pool reward for the period

Slashing on violation:

s = min(p × d, m)

p — slashing percentage (e.g., 0.1 for 10%)
d — custodian deposit
m — cap, to avoid zeroing the deposit entirely

Renting out miner shares

In pools backed by a custodian, miners can rent out their share (mpToken or aggregated hashrate). The custodian acts as an arbitrator: it guarantees redemption to the renter, resolves disputes, and bears responsibility through its slashable deposit.

Process steps

1. Initiation — the lessor calls rentShare(amount, renter, duration, fee), delegating the share and recording the terms.
2. Payment — the renter transfers the rental fee into an escrow contract.
3. Delegation — the share is temporarily associated with the renter in StratumDataAggregator.
4. Monitoring — the custodian tracks the actual delivered hashrate through oracles.
5. Reward redemption — the renter calls redeemRentalRewards; the custodian verifies and signs.
6. Disputes — on hashrate shortfall the renter submits a complaint; the custodian checks oracle data and applies slashing if the violation is confirmed.
7. Completion — at term end the share returns to the lessor.

Rental formulas

Rental fee:

a = p × s × d

p — rental percentage (e.g., 0.05 for 5%)
s — share size in mpToken
d — rental duration in periods

Slashing in dispute:

s = min(v × dep, max_s)

v — violation percentage (e.g., 0.2 for 20%)
dep — violator's deposit
max_s — maximum slashing (cap)

Share rental adds liquidity to the system and turns a stake in a pool into a tradable asset, similar in spirit to decentralized hashrate marketplaces but fully on-chain.

Fee system: wrap, unwrap, NFT discounts

The fee system handles wrap/deposit and unwrap/withdrawal fees for federation and confederation pools. Every change requires FROST approval, and confederations additionally require a custodian threshold.

Contracts

Fee calculation

Fixed percentage:

fee = amount × fixedBps / 10000

Dynamic:

fee = dynamicMinFee + amount × dynamicCoeffBps / 10000

The current implementation caps the computed fee at amount, so a bad dynamic input cannot underflow pool accounting. Config validation rejects fixedBps > 10000 and dynamicCoeffBps > 10000.

NFT discounts

Two fee APIs are available:

function calculateFeeWithDiscount(
    bool isWrap, uint256 amount, uint256 discountBps
) external view returns (uint256 fee)

function calculateFeeWithNFT(
    bool isWrap, uint256 amount, uint256 nftTokenId, address account
) external returns (uint256 fee)

calculateFeeWithNFT consumes allowance through FederationNFTModifier.useDiscountFor. The NFT contract checks ownership, expiration, remaining volume, and increments usedVolume.

Distribution modes

enum DistributionMode { Equal, ByPercentage }

struct DistributionConfig {
    uint256 memberShareBps;
    uint256 custodianShareBps;
    DistributionMode memberMode;
    DistributionMode custodianMode;
}

Validation requires memberShareBps + custodianShareBps ≤ 10000. Equal mode splits the amount across active recipients; ByPercentage mode uses weights.

Security and risks

Security is built on eight independent layers of defense. No single layer is sufficient on its own — an attacker would have to defeat them all simultaneously.

Defense layers

Known risks and mitigations

Production checklist

• Use deployFederationWithCryptographicFROST or deployConfederationWithCryptographicFROST.
• Confirm SimpleFROSTMultisig.counterApprovalsEnabled() == false after bootstrap.
• Build approvals only through target contract helper hashes.
• Disable SPV test helpers via disableTestHelpers().
• Set production confirmation depth; do not rely on the demo constant.
• Register authorized fee collectors and project/global fee managers before traffic.
• Run Slither / Mythril in CI or a dev image.
• Transfer ADMIN_ROLE to a multisig or DAO.

Current test inventory

web3/test/CriticalTests.t.sol currently contains 71 critical tests. Coverage includes: DKG phases and group key validation, strict FROST aggregate approval, BIP340 verifier vector, federation/confederation deploy guards, SPV admin and test-helper protections, MultiPool per-pool accounting and withdrawal locks, redemption escrow/refund and BTC transaction checks, fee config validation and authorized fee collectors, NFT ownership and project wallet share validation.

BTCyield: SatoshiFi × CrossCurve integration

BTCyield is a product layer on top of SatoshiFi infrastructure, built jointly with CrossCurve. SatoshiFi provides cross-chain wrapping and custodial infrastructure through FROST. CrossCurve runs the yield-routing layer via Yield Basis and Silo Finance.

Two partners, one architecture

Three yield streams

Yield strategies

Custodian DAO: the offer

Seat composition:

• 3 seats — investors (open)
• 4 seats — notable participants and influencers (open)
• 4 seats — project founders (reserved)

Confirmed liquidity:

• Cicada — $500,000 (confirmed)
• Hard Core Lab — $2,000,000 (in progress)

Roadmap

1. Now · Liquidity Provisioning Cicada confirmed $500K. Sourcing additional LPs for Solver and Curator. Building the capital base.
2. In parallel · Forming the Custodian DAO 3 + 4 + 4 = 11 seats. Full DAO composition.
3. +2 months · Confederation Launch First confederations after DAO and liquidity are in place. DKG ceremonies. Connecting confederations to Solver and Curator.

Stream comparison

Frequently asked questions

Glossary

mpToken

Local ERC-20 pool token, 1:1 backed by the native asset. Issued by MiningPoolDAO. Freely transferable, redeemable to the native network, or convertible to sToken.

sToken

Global network ERC-20 token (SBTC, SDOGE, SBCH, SLTC). Issued by MultiPoolDAO per network. Provides liquidity and redemption to native assets.

MiningPoolDAO

The local mining-pool contract. Accepts shares, verifies via SPV, distributes rewards through calculators, mints mpToken.

MultiPoolDAO

The global coordination contract for one network (BTC, DOGE, BCH, LTC). Verifies UTXOs, issues sToken, coordinates redemption through FROST.

SPV (Simplified Payment Verification)

Verification mechanism that does not require running a full node. Uses block headers and Merkle paths.

FROST (Flexible Round-Optimized Schnorr Threshold)

Threshold-signature protocol for secp256k1. A t-of-n threshold delivers decentralized signing.

DKG (Distributed Key Generation)

Distributed key generation. Each participant holds a share of the private key; the group public key is formed collectively.

BIP340

Bitcoin Improvement Proposal 340 — the secp256k1 Schnorr-signature standard used in Taproot. Requires even-Y coordinates for public keys and R points.

CalculatorRegistry

Registry of reward calculators (PPS, FPPS, PPLNS, Score). Supports registration, whitelisting, and usage statistics.

PPS / FPPS / PPLNS / Score

Reward distribution models: fixed payment per share (PPS), with tx fees (FPPS), over a window of last N shares (PPLNS), exponential decay (Score).

PoolMembershipNFT

Soulbound token confirming a miner's participation in a pool. Non-transferable.

PoolRoleBadgeNFT

SBT for DAO roles (admin, validator, etc.).

Stratum

Network protocol for transmitting miner share data. Integrated through StratumDataAggregator and StratumDataValidator.

UTXO (Unspent Transaction Output)

Unspent transaction output. Verified via SPV to confirm rewards.

DAO (Decentralized Autonomous Organization)

An organization governed through smart contracts and tokens (mpToken, NFT/SBT).

Federation

A group of participants jointly holding shares of a BTC address key through DKG. A t-of-n threshold gates all operations.

Confederation

A federation plus a custodian layer. Every operation requires both a FROST threshold and a custodian threshold simultaneously.

Custodian

A trusted participant from MultiPoolDAO holding a key share through FROST. Guarantees honesty through a slashable deposit.

Slashing

Confiscation of a participant's deposit (custodian, oracle) for proven violations. Aligns incentives toward honest behavior.

Backing

Reserve struct: totalReceived, reserved, available. sToken issuance is bounded by available.

Operation Hash

Target-bound hash of a privileged operation. Includes domain, chainid, FROST address, target contract, selector, parameter hash, and nonce.

RBF (Replace-By-Fee)

Bitcoin standard for replacing an unconfirmed transaction with one carrying a higher fee. SatoshiFi uses RBF-compatible sequence policy to accelerate redemption.

Proof-of-Reserves (PoR)

Proof that all issued wrapped tokens are backed by native assets on federation addresses. In SatoshiFi this is fully on-chain through BridgeInbox and events.

References and licenses

Academic and standards references

1. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
2. Komlo, C., & Goldberg, I. (2020). FROST: Flexible Round-Optimized Schnorr Threshold Signatures.
3. Feldman, P. (1987). A Practical Scheme for Non-interactive Verifiable Secret Sharing.
4. BIP-340 — Schnorr Signatures for secp256k1.
5. BIP-32 — Hierarchical Deterministic Wallets.
6. SEC2 — Recommended Elliptic Curve Domain Parameters (secp256k1).
7. EIP-2565 — Modular Exponentiation Precompile Gas Cost.

Technology partners

• CrossCurve — Garden Solver, Curator, Yield Basis integration
• OpenZeppelin Contracts — AccessControl, ReentrancyGuard, Pausable, ERC20, SafeERC20
• Yield Basis — cyb-tokens, BTC vaults
• Silo Finance — BTC wrapper lending, stablecoin deposits

Auditors and tooling

• MixBytes — audit of CrossCurve Curator
• SmartState — planned audit of SatoshiFi
• Hexens — planned audit
• Slither, Mythril — recommended static analyzers in CI
• Foundry / Hardhat — development and testing frameworks

Licenses

Smart contract code and documentation are distributed under the MIT license (SPDX-License-Identifier: MIT). Dependencies (OpenZeppelin Contracts and the project's own libraries — BlockHeader, BitcoinUtils, MerkleProofLib) are also MIT.

Repository and contacts

• GitHub: github.com/SatoshiFi
• Website: unilayer.solutions
• BTCyield: btcyield.online
• Issues and pull requests are accepted through GitHub