anypayHow it works
Every fee has
a destination.
A token creates the opportunity. The contract records the allocation. A payment provider completes the journey to your chosen recipient.
Understand what happens at each stage, which rules are written into the contract, and what needs to happen before funds reach an account.
80% recipient allocation 20% protocol allocation
From a token to a payment.
AnyPay connects creator fees earned on pons.family with a recipient and a selected payment route. The journey has five stages, each with a distinct responsibility.
Register the destination
Choose a method and register the recipient’s account. The private account record is linked to a public alias and reference.
Launch through AnyPay
Create the token on pons.family with AnyPay designated as its creator fee recipient.
Collect creator fees
Trading activity generates fees under the token’s launch terms. A harvest claims available creator fees from the pons escrow.
Record the allocation
The contract books the claimed ETH into recipient and protocol pools. Its events provide a record of that allocation.
Fund and process the payment
The operator withdraws and converts funds, then funds the provider. The keeper submits eligible payments and tracks confirmation.
A contract event proves that fees were allocated on chain. A confirmed provider payment records the outbound settlement. Allocated funds can still be waiting for payout.
A recipient, with a defined route.
Start with the person you want to receive creator fees, then select an available payment method. PayPal and Venmo use account identifiers; bank and eligible debit-card routes use provider-issued account references.
Private account information is kept in an encrypted off-chain vault. The public contract stores the recipient alias, method ID and opaque reference. It does not store the recipient’s email, bank details or card number.
struct SettlementRoute { uint8 method; bytes32 recipientRef; }method identifies the payment route. recipientRef links to the private account record. The account must be reviewed before it can receive a live payout.
The route is fixed when an alias is first used. Reusing that alias with a different method or reference causes the launch to revert with SettlementMismatch(). This keeps later launches from silently replacing an existing destination.
Your token. A lasting fee route.
Choose the token’s name, ticker, artwork and optional creator tax. Launching requires the current pons launch fee and network gas. An optional first purchase sends tokens to the launching wallet.
AnyPay calls the pons factory and records the resulting token, curve, creator and recipient alias. Only tokens created through this flow appear in the AnyPay registry.
creatorFeeRecipient: address(this),This launch parameter directs creator fees to the AnyPay contract. The current contract exposes no function to transfer that fee destination. Withdrawal and settlement still depend on the operator.
Creator fees accrue under the pons trading terms, including any creator tax selected at launch. The contract checks the maximum creator tax and launch fee against pons when the transaction executes.
The 80/20 rule, in the contract.
A harvest collects available creator fees from the pons escrow. Anyone can call it. Harvesting moves funds into AnyPay and updates its accounting; it does not send a fiat payment.
uint256 public constant RECIPIENT_BPS = 8_000;
uint256 private constant BPS = 10_000;One basis point is one hundredth of a percent. 8,000 out of 10,000 sets the recipient share to 80%. The remainder is recorded for the protocol.
uint256 r = doNotPay[l.handleKey] ? 0 : amount * RECIPIENT_BPS / BPS;
uint256 pr = amount - r;amount is the creator fee amount attributed to a token during harvest. r is the recipient allocation; pr is the protocol allocation. Integer division rounds the recipient share down to whole wei, the smallest ETH unit.
If the alias is marked doNotPay, its recipient allocation is zero and that attributed amount goes to the treasury. The normal split therefore has an explicit blocking exception.
- Recipient pool
- 0.8 ETH
- Protocol treasury
- 0.2 ETH
Illustrative allocation for an unblocked recipient. The contract accounts in ETH. The final amount received depends on valuation, conversion and provider charges.
Fees swept by the pons operator before a harvest may arrive without a per-token attribution in that harvest. The contract emits UnattributedClaimed and applies the same pool split; the keeper reconciles attribution using pons events.
An allocation becomes a payment.
The recipient pool holds ETH. The owner withdraws funds for conversion through an approved off-ramp and funds the payment provider. Smart contracts cannot directly credit a bank account or payment app.
function withdrawPayouts(address to, uint256 amount) external onlyOwner nonReentrant {onlyOwner restricts this withdrawal to the contract owner. nonReentrant guards against re-entering the operation during execution. Recipients rely on the operator to fund and complete settlement; there is no recipient self-withdrawal function.
When a payment becomes eligible
The keeper, an off-chain service, values collected fees in USD and tracks each alias’s lifetime credited total. Payout milestones are part of the keeper’s settlement rules, separate from the Solidity allocation rule.
- $5
- $10
- $20
- $50
- $100
- $250
- $500
- $1,000
After $1,000, milestones continue at every additional $1,000. Crossing a new milestone makes the entire unpaid balance eligible, rounded down to cents, subject to account approval, provider availability and funding.
An approved alias with $7 in lifetime credits and no previous payout can allocate $7 at the $5 milestone. If its lifetime credits later reach $12 after that payment completes, its next allocation is the unpaid $5 at the $10 milestone.
Read the payment status
- Allocated
- Fees have been credited. Some or all of the balance may still be waiting for the next payout milestone.
- Pending
- A payment has reserved funds and is awaiting a confirmed outcome. Provider acceptance alone does not establish completion.
- Paid
- The provider has confirmed the outbound payment. Availability in the destination account can still depend on its bank or service.
- Simulation / sandbox
- Test activity is labelled separately and excluded from real payout totals.
Clear rules. Visible responsibilities.
AnyPay combines on-chain accounting with operator-managed settlement. Understanding who can act is part of understanding the product.
- Anyone
- Can harvest fees for registered tokens. Funds remain in the contract’s pools until withdrawn.
- Owner or keeper
- Can mark an alias as do-not-pay. This blocks new launches for that alias and redirects its future attributed harvest allocations to treasury.
- Owner
- Can pause new launches, disable methods for new launches, manage keepers and change the launch configuration. The owner can withdraw either pool and recover ETH or ERC-20 tokens in an emergency.
- Payment operator
- Reviews recipient accounts, funds provider balances, submits payments and reconciles uncertain outcomes.
Emergency ETH recovery can use funds from both pools. It consumes unaccounted ETH first, then treasury funds, then recipient funds. This is a custodial settlement model: the contract’s accounting does not remove operator control over those funds.
Read about stopping payments →Before you begin.
Does 80% mean 80% of a trade?
The split applies to creator fees actually collected by AnyPay. Trade volume, token price and token supply are separate quantities. Fees depend on trading activity and the launch terms; launching a token does not guarantee revenue.
Can I change the recipient after launch?
The contract fixes a settlement method and recipient reference for each alias when it is first used. Later launches using that alias must match the same route. A different destination requires a new reference and alias for a new launch; it does not reroute fees from existing tokens.
Does a recipient need a crypto wallet?
The selected payment route uses the recipient’s approved provider account. The creator connects a wallet to register the recipient and launch a token. A creator’s wallet signature does not prove ownership of a third party’s payment account, so recipient review remains necessary.
Why might an allocated balance remain unpaid?
The next lifetime earnings milestone may not have been reached, the recipient may be awaiting review or suspended, or the provider may lack funding or eligibility. A payment already in progress also reserves its allocation until its outcome is reconciled.
Is every payment method available now?
The website displays availability for each method. A listed route still depends on provider setup, country, currency and account approval. PayPay is simulation-only in this implementation. Simulation and sandbox activity do not count as real payouts.
What happens if a payment result is unknown?
The keeper retains the payment request and reserves the funds for reconciliation. Retries use the same request identity. An uncertain response is not treated as proof that no money moved, and it does not automatically release those funds to the treasury.
Follow the record.
The excerpts above quote contracts/src/AnyPay.sol in this project. They explain the implementation; they are not a claim that a deployed address has been independently audited or source-verified. Use the explorer links below to inspect configured contract addresses and their activity.
FeesAttributed records per-token allocations during harvest. Harvested records the overall claim and split. PayoutsWithdrawn records an owner withdrawal from the recipient pool. None of these events alone confirms a fiat payment.