From a launch
to a builder’s next step.

What PaidIn does

PaidIn lets communities direct creator revenue toward builders: an early startup, an open-source developer, a robotics team member or someone building a useful product. The launcher chooses one LinkedIn or individual GitHub profile. That recipient verifies ownership and binds a payout wallet when ready.

New launches use Four.meme on BNB Chain and pump.fun on Solana. The form offers the networks this deployment can use. “Soon” means a route is not available yet. Read the final allocation before approving: EVM values come from the registry; Solana uses the platform allocation described here.

Revenue depends on eligible activity and collection. Token creation, volume or market cap does not guarantee income. The token does not represent equity in the recipient’s company or grant rights to its products.

Choose your role

Launching does not require social sign-in. Wallet connection and profile verification are separate: a connected trading wallet does not prove ownership of a social account.

1. Launcher: open Launch, choose a network and complete the form.
2. Recipient: open Payday and verify the named provider.
3. Then bind the payout wallet and inspect earnings.

Launch on BNB Chain · Four.meme

PaidIn prepares a Four.meme tax token with founder revenue directed to a dedicated PaidIn vault. The vault records the beneficiary and platform allocation before token creation. The token follows Four.meme’s bonding curve and migration lifecycle.

Complete the form

1. Choose BNB Chain and connect the creator wallet.
2. Add name, ticker, image and optional description.
3. Select LinkedIn or GitHub and enter one username or profile URL. Wait for resolution and check the identity.
4. Choose an offered buy/sell tax: 1%, 3%, 5% or 10%. This is separate from launchpad fees.
5. Optionally add a first buy and project links. Zero initial buy is allowed.
6. Review beneficiary, vault, tax, first buy, network and costs.

Understand the wallet steps

The login message is not token creation. The vault and token calls are transactions. PaidIn checks token details, tax recipient, first buy and launch fee. Simulation reduces avoidable errors but does not guarantee execution or resolve wallet security alerts.

If only the vault was created

A vault can exist while token creation is incomplete. Prepared-launch recovery refreshes the request only after checking the original creator, token details and on-chain allocation. Resume that launch; another beneficiary cannot repurpose its vault.

Four.meme controls tax collection, conversion and dispatch. Upstream revenue is not immediately claimable from PaidIn. BNB and WBNB received by the vault follow its accounting; WBNB is unwrapped on payout.

Launch on Solana · pump.fun

Solana uses pump.fun with SOL or USDC as quote asset. Revenue routes to the recipient’s PaidIn escrow and platform account. GitHub recipients use this same escrow route, not pump.fun’s separate social-account claim product.

Prepare, sign and confirm

1. Choose Solana and connect a compatible wallet.
2. Choose SOL/USDC, add token details and resolve one recipient.
3. Review allocation and account-creation, network and locking costs. USDC launches still need SOL for fees and rent.
4. PaidIn uploads metadata, builds and simulates the transaction. An initial buy is included only if this deployment has the required setup.
5. Your wallet signs. PaidIn validates the recorded intent, adds the mint signature and submits the prepared transaction.
6. After creation, PaidIn completes and confirms the protocol revenue lock.

Revenue lock and recovery

Coin creation and revenue locking have separate completion states. A pending lock is shown on the token page with a retry. Retrying uses the recorded allocation; it does not create another token or beneficiary.

Pre-lock fees remain attributable to the launch creator account. Recovery routes them to the recorded accounts after locking. Scheduled and claim-time collection distribute protocol revenue. Trading may occur before an escrow balance appears.

The route covers the graduated market when the relevant collection/distribution instructions succeed. Revenue waiting inside the protocol differs from funds already in the recipient escrow.

Understand the revenue

BNB revenue waits in the token vault. Solana distributions pay a recipient escrow that gathers the profile’s revenue. Unverified ownership or a missing wallet does not redirect it to the launcher.

The beneficiary reference and allocation are fixed. Page editing, account verification and wallet changes cannot select another beneficiary. Existing tokens keep their recorded allocations.

Verify the named profile

GitHub: automatic match

1. Connect GitHub using the named individual account.
2. PaidIn checks GitHub’s authenticated user and stable numeric account ID.
3. The profile shows Verified owner; public name/photo follow your preferences.

A public username lookup is designation, not proof. Usernames can change or be reused; the numeric ID preserves the same account’s reference after renaming.

Login requests public data only, with no private repository/private email access. The OAuth token is not retained after checking the user. Organization and repository recipients are unsupported; choose an individual maintainer.

LinkedIn: review the public profile

1. Connect LinkedIn on Payday.
2. Submit the named public profile URL.
3. Place the displayed code in the headline or About section.
4. Wait for review, then remove the approved code and bind a wallet.

Sign-in identifies the account but does not itself confirm the public profile URL a launcher entered. Review establishes that relationship. Display-name/email matching is insufficient; LinkedIn and GitHub identities are not automatically merged.

Bind a payout wallet

The payout wallet receives fees and may differ from launcher/trading wallets. Sign in as verified owner, select Bind a payout wallet, choose the network and connect a wallet you control. Read the address, profile, network and expiry before signing; wait for confirmation.

EVM authorization

The EIP-712 message contains reference, wallet, registry, chain, nonce and expiry. The identity server provides a separate signature; the registry checks both. PaidIn’s relayer pays for binding. One registry’s signature is not universal network authorization.

Changes and cancellation

Claim can finalize an EVM change after its delay. Freeze or forced-rebind states may still block payment. The app checks actual registry state.

Email alerts require an available email and configured notification service. GitHub login collects no private email, so GitHub recipients must not rely on email wallet-change alerts.

Claim available fees

1. Sign in with the owning profile.
2. Check network wallet and pending changes/holds.
3. Refresh available earnings.
4. Claim an eligible balance; destination comes from the bound wallet, not a request-supplied address.
5. Inspect the confirmed explorer transaction.

BNB claims

The server checks ownership, confirmed launch, vault allocation and registry wallet, simulates the claim and estimates gas. The current sponsored minimum is five times estimated gas cost. Smaller balances remain recorded.

Solana claims

PaidIn collects/distributes eligible revenue, resolves the effective wallet and transfers escrow balances. Minimums are currently 0.001 SOL or 1 USDC per asset. A USDC associated account may need setup.

Solana escrow keys are held by PaidIn’s server, requiring trust in key management and service availability. EVM balances remain in contracts following vault/registry rules. These custody models differ.

Pending/failed requests and “nothing waiting” are not proof of payment. Verify amount and destination in the confirmed record. Operation locks and recorded intents protect against duplicate in-flight requests.

Manage a project page

Launcher proposals and recipient statements are distinct contributions. A proposal can precede recipient participation; the page shows that status clearly.

Launcher editing

Choose “I created this token · edit” and sign with the recorded creator wallet. The message names the site, token, network, wallet, nonce and expiry. It authorizes one hour of editing, not a payment. The challenge expires after five minutes and is single-use.

Published material is saved on the server and loads in future editor sessions. Version checks prevent a stale form from silently overwriting a newer revision.

Media

Paste a valid HTTPS YouTube video link. PaidIn normalizes its ID and embeds the player, not arbitrary HTML. Removed, restricted or embedding-disabled videos may not play.

Upload up to four PNG/JPG/GIF/WebP images, at most 4 MB each. Captions are optional. File bytes/formats are validated; external image URLs do not replace uploads.

Recipient participation

After verification, use Manage my statement. Joining requires a statement; updates belong to that account. Claiming does not require joining, agreeing with the launcher’s story or posting updates.

Market data and trading

Use the full address, network, explorer and launchpad links on a confirmed token page. Names/tickers are not unique identifiers.

Before Four.meme migration, trading follows its curve. The app links to that market if a DEX chart is unavailable. DexScreener charts require an indexed supported pair. A missing chart does not automatically mean launch failure.

Graduation and third-party indexing are separate. PaidIn cannot guarantee terminal listing speed or availability. “Liquidity data unavailable — trade blocked” means a route’s liquidity was not established; it does not describe recipient fee balances.

Quotes, cap, volume and progress may be delayed/unavailable. A dash means missing data; zero is numeric. Revenue and volume measure different things.

Privacy and consent

Show me in discovery controls public name/photo and profile search. Allow new launches to name me controls future designation. Neither rewrites transactions or cancels recorded revenue.

LinkedIn provides account identity, name, photo and email through configured permissions. GitHub provides public ID, username, name and avatar. Verified identity authorizes profile changes and claims.

The chain stores an internal-ID-derived reference, not name/email. Public pages may associate it with a profile; it does not make participation anonymous. Wallets/transactions remain public and third-party copies may persist. Read Terms & privacy.

Signatures and operator control

Ownership verification is not a project audit or endorsement. A wallet alert can concern site, address or behavior; simulation and official addresses do not clear it. Cancel a flagged request, inspect its details and report incorrect classification through your wallet. No warning-free guarantee is made.

Service responsibilities

PaidIn manages matching, signer/relayer keys, deployment settings, abuse review and sponsored operations. EVM administration manages signers, admin settings, delays and emergency controls according to the contract; it cannot edit locked vault beneficiaries/allocations.

Solana operations manage creator setup, distributions and escrow keys. Service/RPC outages can delay refreshes or payments. Address publication is not an independent audit certificate.

Contracts and addresses

Revenue vault

The Four.meme factory creates a dedicated vault recording beneficiary and platform allocations. It accepts BNB/WBNB revenue and reads the registry for the effective wallet. Use the token page’s confirmed vault links.

Identity registry

The registry tracks binding, nonce, pending wallet and emergency state. Its EIP-712 domain isolates chain/registry authorization. A reference is keccak256(abi.encode("paidin.ref.v1", recipientId)).

Configured deployment

PaidIn addresses come from this server. Compare them with GET /api/v1/chains and the launch review.

API reference

Paths are relative to /api/v1. JSON writes use Content-Type: application/json; uploads/launch forms use multipart. Protected writes require session, proof and same-site checks. Secrets, signing keys and relayer keys belong only on the server.

Resolve one recipient

POST /api/v1/recipients/resolve
Content-Type: application/json

{ "provider": "GITHUB", "input": "username" }

// JSON string in the multipart launch form:
recipients = [{ "id": "resolved-recipient-id", "bps": 9000 }]

This uses the default 90% in basis points; read the selected network’s allocation. Resolution returns id, refHash, provider, URL and public connection state, not claim/edit authorization. Do not alter prepared destinations, values or parameters; confirmation checks actual chain results. Administrative/scheduled endpoints require service authorization.

Current limits

Network fees, rent and protocol charges change; inspect the prepared request and wallet review. Production rate counters use the shared database; local development has a fallback. Limits do not guarantee transaction success.

Find the next step

HTTP errors

Errors return an error message: 401 sign in; 403 forbidden; 404 unknown record; 409 conflict/pending; 410 expired; 413 too large; 422 invalid input; 429 rate limit; 502/503 service/upstream unavailable.

Report page URL, network, token address, public transaction hash and visible error. Never include private keys, OAuth codes, secrets, session cookies or recovery phrases.

Common questions

Further reading

This guide describes PaidIn. Upstream references explain protocol mechanisms; they do not verify ownership or certify a PaidIn deployment.

• Four.meme tax-token guide ↗
• pump.fun revenue instructions ↗
• GitHub identity best practices ↗
• GitHub OAuth scopes ↗
• MetaMask security alerts ↗