Launch a token
You will need a compatible wallet on Robinhood Chain and ETH for the launch, setup fee and gas.
- Choose your plan.
Open Create a new token and choose a basket rule. With basket buys on, creator fees buy assets for your token’s holders. With basket buys off, creator fees go to your launching wallet and no Lore basket is created.
- Set the token profile and pair.
Enter your own name and ticker, add a logo and any profile links, then choose the asset your token trades against. If you are following a wallet or group, use the intended public addresses; an example does not imply that anyone endorses your token.
- Add a developer buy if you want one.
Leave the ETH budget blank or at zero to skip it. A positive budget creates the token and buys it in one transaction, sending the tokens to your launching wallet. A failed buy reverts the whole launch. Unspent funds return to your wallet in ETH or the paired asset.
- Review, then confirm in your wallet.
Check the token image and identity, paired asset, creator-fee destination, developer buy and fee breakdown. The total is the live PONS launch fee plus the Lore setup fee and any developer budget; wallet gas is additional. Keep the transaction hash and wait for finalized confirmation. If confirmation is delayed, check the existing transaction before launching again.
An ETH pair buys directly on the new PONS bonding curve. For another paired asset, your ETH first buys that asset on an existing market, where the conversion price can move before the transaction lands. The default tolerance is 1%; Advanced lets you choose 0% to 5% in steps of 0.01%. The reviewed minimum protects both token output and any quoted paired-asset refund. ETH-paired buys require the full quoted token output and have no slippage setting.
After launch: everything is optional
The confirmation checklist links to your PONS market and, with a basket, your Lore page once indexed. You can also add a paid DEX Screener profile once your market is supported, or create an X account and share the token address and PONS link. Use an existing account if you prefer. No extra payment, social account or completed checklist is required.
To return later, open Create / Launch or My Lore in the same browser and select your saved launch. You can check the existing transaction and reopen the checklist without submitting another launch. Keep the transaction hash if browser storage is unavailable or you clear site data.
The setup fee’s independent buy is separate from your optional developer buy. Its reserve is included in every Lore launch, even with basket buys off, and the tokens go to the configured independent buyer.
Use an existing token
This attaches a creator-fee plan to an existing PONS token. It does not create another token.
- Prepare the plan.
Open Use an existing token, enter its address and choose the basket rule. Preparing the candidate costs transaction gas and gives you no control over the token or its fees.
- Arrange the fee handoff.
Share the prepared CTO page with your community; readers can inspect it without connecting a wallet. The current creator-fee recipient can transfer future fees voluntarily. Otherwise, an eligible community takeover must go through PONS’s timed process. Follow the next action and deadline shown on the proposal page.
- Activate after the handoff.
Once PONS names the exact prepared plan as creator-fee recipient, anyone can pay the Lore setup fee plus gas to activate it. The setup includes the same operations payment and independent buy reserve. Then wait for indexing and the first complete observation window before a basket round can begin.
The basket rule is fixed when prepared. The publisher has a separate 48-hour handover policy; it does not let the creator edit the basket rule or immediately redirect assets.
Receive holder payouts
Hold the token whose creator fees fund the basket. Rewards arrive as the acquired assets themselves.
- Find the token and its rounds.
Open Lore activity, select the token’s basket and open a payout round. Your share uses eligible balances over the 30-minute holder window, not just your balance when you open the page.
- Let the round finish.
Acquisition opportunities are 30 minutes apart. ETH-funded plans accumulate rewards until a first asset is worth at least $1 and delivery gas is at most 33% of its value. Later payouts become eligible six hours after the last funded payment. You do not need to connect or sign to receive automatic transfers. Missing prices, fees, data or services can delay delivery.
- Use the fallback only if needed.
On a distributable round, open Manual fallback, connect the eligible wallet and choose Send mine now. The interface checks your proof and skips assets already paid. Your wallet may ask for a separate transaction for each unpaid asset, and you pay the gas. The proof service must be available.
A missing round or delayed transfer does not by itself mean you are ineligible. Check the failure and waiting conditions. There is no contract claim deadline; a valid unpaid entitlement remains claimable.
What Lore does
Lore connects three separate things: the token that generates creator fees, the rule that builds a basket, and the holders who receive the assets bought in each round.
PONS creator fees become the strategy’s spending budget after the applicable fee sweep and escrow claim.
The rule can use fixed assets, one wallet, a wallet group, or the launch token’s holders as its source.
Each bought asset is distributed separately according to eligible holders’ time-weighted launch-token balances.
Lore does not stream assets every second. The keeper submits proof-bound transfers once completed rounds have accumulated enough value for economical delivery.
Plan and activation
A plan is encoded as a canonical methodology document. Its hash and publisher address are placed into an isolated strategy contract for one PONS token and one paired asset.
Launch with the rule attached.
When basket buys are enabled, the factory creates the strategy and asks PONS to send that token’s creator fees to it from launch. Turning basket buys off creates no launch-time Lore strategy. Adding one to the token later would require the separate existing-token handoff and activation flow.
Prepare, hand off, activate.
Anyone can prepare a candidate strategy, but preparation gives no control over the token. PONS or the current creator must first name that exact strategy as creator-fee recipient. Activation succeeds only after the canonical PONS record confirms the handoff.
The factory registers at most one active Lore strategy per token. A prepared CTO strategy stays inactive until the creator-fee handoff is visible onchain.
Choose a basket rule
| Mode | Source | What determines the basket |
|---|---|---|
| Fixed basket | Creator-selected assets | The configured assets and weights remain fixed in the methodology. |
| Follow one wallet | One public address | Its top 20 eligible positions become portfolio shares by paired-asset value. |
| Follow a group | 2 to 64 public addresses | Each wallet’s top eligible positions are normalized into a portfolio, then the portfolios are combined with equal source weight. |
| Follow the holders | Launch-token holders | Normalized portfolios from up to the top 1,000 time-weighted holders are combined by holder weight. |
Dynamic modes currently offer a 5, 10 or 20 asset cap and proportional or equal basket weighting. The default is up to 20 assets with proportional weighting. These choices are part of the plan.
Wallets and holders
Lore first turns each source wallet into a value-weighted portfolio. Follow the holders then combines those portfolios by holder weight.
- Reconstruct holder balances.
The indexer reads launch-token transfers and rebuilds balances at finalized sample boundaries.
- Measure the full window.
Balances are sampled every 5 minutes across the previous 30 minutes. Missing boundary data causes the round to wait.
- Rank the source set.
Each wallet receives a time-weighted average launch-token balance. Lore removes system and excluded addresses, ignores balances below one raw base unit, sorts the remaining values from highest to lowest, and keeps up to the top 1,000 eligible holders.
- Resolve the eligible universe.
At one finalized block, Lore considers the mature candidates in the plan’s shared routable universe. This is a bounded eligible set, rather than discovery of every ERC-20 held by each wallet.
- Estimate paired-asset value.
Each candidate’s committed acquisition route is quoted with the plan’s base amount and again with exactly twice that amount. A candidate is excluded when the two quotes imply more than 5% price impact.
- Build each wallet portfolio.
Lore applies the route-implied price to the wallet balance, keeps its top 20 positive eligible positions by estimated value, and divides each retained value by their total. The result is that wallet’s normalized portfolio shares.
- Combine source influence.
A larger time-weighted launch-token holder contributes more to Follow the holders. Follow a group combines normalized wallet portfolios with equal source weights. Follow one wallet uses that wallet’s normalized portfolio directly.
- Filter and rank assets.
Unsupported, excluded, unroutable, high-impact, and zero-score assets do not qualify. Remaining asset shares are added across source wallets, then ranked by aggregate score, with address order used as a deterministic tie-break.
- Select and weight the basket.
The rule selects the final Top 5, Top 10 or Top 20 assets. Proportional mode follows aggregate score. Equal mode gives the selected top assets equal target weights.
They use finalized executable acquisition-route quotes in the strategy’s paired asset. They are not USD prices, full-wallet discovery, pool-depth measurements, or promises that the whole wallet position could be liquidated at that value.
The top source holders shape the basket. Every eligible launch-token holder is included in the payout tree. The top 1,000 limit does not limit who can receive assets.
Time weighting, the curated universe, two-size route checks, the per-wallet position cap, and top-N selection reduce simple dusting, thin-route, and short-lived balance attacks. They do not make the result manipulation-proof. Holding eligible assets is the intended way the source set influences the basket.
How assets qualify
New screened plans bind a screened registry and its safety policy. Discovery looks for PONS launches and Robinhood Chain tokens with supported acquisition routes. Discovery does not make a token eligible: pending, failed, quarantined and expired screens are excluded. The current candidate count and admitted capacity are shown before launch or CTO preparation.
- Screening: a local chain fork tests buying, transferring to a recipient, and selling with the supported route. The bound policy rejects detected transfer tax and observed trade fees at or above 10%. Evidence records the tested block, route, result and expiry. A passing test is evidence about that state, not a guarantee against hidden restrictions or later contract changes.
- Compatibility: PONS assets may use their canonical curve or V4 route. External ERC-20s need a committed supported route.
- Initial data: a newly admitted or re-admitted asset waits one full 30-minute observation window before a screened plan can consider it, including fixed allocations.
- Per-round checks: the route must quote successfully at the finalized block for the plan minimum. Dynamic candidates additionally quote twice that amount and must stay within the plan’s 5% two-size price-impact limit. PONS routes still use their curve reserve or graduation seed as an available-liquidity signal. External routes must return positive output. These checks confirm bounded executability, and they do not measure total pool depth. The pilot base quote is 0.001 paired-asset units.
- Exclusions: the launch token cannot buy itself. Configured excluded assets, reference tokens, invalid assets, and tokens with no positive supply are removed.
- Freshness: new web plans require screening no older than one hour. The publisher rechecks current safety status before a new proposal and immediately before signing. The managed keeper also rechecks the exact committed asset and route before a new purchase, including after the activation delay. A suspended asset, expired evidence, unhealthy registry, policy mismatch or RPC failure defers that action.
- Fixed baskets: their non-quote assets also need current passing screens. If a fixed asset becomes ineligible before proposal, the round waits. After proposal, the managed keeper defers that purchase; previously acquired assets can still be paid out. The promised weight is not silently reassigned.
- Token behavior: fee-on-transfer, rebasing, and other tokens that break exact balance-delta accounting are outside the supported scope. A token can still hide behavior from a simulation or change after the tested block.
The screening operator, its discovery sources and its tests remain trusted offchain components. Registry inclusion is not an endorsement, valuation or promise of future sellability. Broad discovery does not mean every chain token can be screened or admitted continuously.
How the shared universe changes
The screened registry preserves hash-chained history while recording new screening results and suspensions. Re-admission must respect the observation window. Every round pins the historical version and candidate set it used; later safety changes can stop a new proposal but do not rewrite that artifact or cancel an already signed or onchain proposal.
These checks govern Lore’s managed launcher, publisher and keeper. They do not prevent another permissionless caller from executing an onchain commitment. A purchase hold preserves transaction reconciliation, expiry finalization and payouts from already acquired assets; it does not change the committed basket.
New screened plans take their candidate limit from the backend’s admitted capacity, with a schema ceiling of 1,024. Expired and quarantined entries are filtered before that limit is applied. If more mature eligible candidates remain, ascending token address selects the bounded candidate set before portfolio scoring. The final basket still obeys the strategy’s smaller asset cap. Discovery, screening and runtime capacity are separate limits.
Historical v1–v3 plans retain their original hashes and rules, including their original registry behavior and candidate caps. Reading an old plan does not add v4 screening promises to it.
Scoring and weighting
Weights follow the scores.
Lore takes the highest-ranked eligible assets and converts their aggregate scores into basket weights. Assets below the configured minimum weight are removed, and the remaining weights are recalculated.
Top assets get equal weights.
Lore takes the highest-ranked eligible assets, then splits the dynamic allocation equally. Any indivisible basis-point remainder is assigned deterministically by address.
Every final basket must total exactly 10,000 basis points. Each asset receives a nonzero quote budget. For a fixed basket, the chosen weights must already total 10,000 basis points. For a dynamic basket, Lore derives valid weights after scoring and filtering.
How a cycle runs
Thirty minutes is the earliest proposal cadence for the configured pilot. It is not a guaranteed schedule.
- 01Fees become usable budget.
PONS creator fees are swept and claimed into the strategy in its paired asset.
- 02Prerequisites are checked.
The previous round must be closed, complete source and recipient data must exist, routes must work, and the available budget must meet the 0.001 paired-asset pilot minimum.
- 03The indexer compiles a deterministic artifact.
It records the finalized block, basket, weights, budget, recipient tree, universe version, aggregate evidence hash, and code commit. The evidence hash commits to the underlying sample and portfolio hashes held by the operator.
- 04The publisher proposes the round.
The onchain proposal contains the assets, weights, routes, minimum outputs, budget, recipient root, total recipient weight, and evidence hash.
- 05The proposal waits 5 minutes.
The activation delay makes the commitment observable before purchases can begin. The current contract has no proposal-cancellation vote during this delay.
- 06Assets are bought during a 10-minute window.
Any caller can execute one unfilled basket leg. The keeper normally performs these transactions.
- 07The round becomes distributable.
A fully executed round finalizes immediately. After the deadline, anyone can finalize a partial or unexecuted round.
The proposed round normally reserves the creator-fee purchase budget available after the operating reserve and other commitments, subject to any maximum encoded in the plan. The amount must be large enough to give every selected basket leg a nonzero allocation.
Purchase protections
The publisher commits a minimum output for every swap. At execution, the strategy requotes the same route and raises that minimum when needed to enforce the factory’s 5% maximum-slippage guard. The adapter checks actual balance changes against reported spend and output. Routes cannot introduce an arbitrary spender or redirect acquired tokens away from the strategy.
If a basket constituent is the ERC-20 paired asset itself, that leg can be allocated directly without a swap. Native ETH cannot be a direct distribution leg.
How holder payouts work
Payout eligibility uses the launch token, regardless of which source shaped the basket. Lore measures every eligible holder across the same 30-minute window, with balances sampled every 5 minutes. System addresses and configured exclusions are removed.
New ETH-funded plans use cumulative automatic delivery: one first asset worth at least $1, with quoted delivery gas at most 33% of its value. Later payouts are eligible every six hours and may include up to 20 assets; the same gas ratio applies without a second $1 minimum. Six hours is a minimum interval, not a guaranteed payment time. Unpaid amounts remain owed after a holder sells.
The creator completes a separate payout-setup transaction before the first purchase round. It fixes the payout operator and reserves 10% of newly claimed creator fees for operations, leaving 90% available for purchases. The publisher waits for finalized setup. The operator can withdraw the reserved share; compensation is a conservative maximum cost, not measured gas reimbursement.
The automatic service requires fresh USD valuations, sufficient native reserves and keeper gas. A missing or unsupported price defers that asset. Token-denominated creator fees retain per-round proof-based payouts and a manual fallback; automatic reserve conversion into native gas is not implemented.
Every acquired asset is calculated separately:
- The recipient commitment is a Merkle root. Each leaf binds the chain, strategy, round, recipient, and recipient weight.
- Lore’s keeper verifies each original round proof and combines rewards into one transfer per recipient and asset. Accumulated transactions permit at most 256 source claims and 128 recipient/asset groups; the keeper defaults to 64 groups and reduces or defers oversized batches. Legacy direct claims retain their 16-claim contract limit.
- The holder does not need to sign the normal keeper submission. Assets can only be transferred to the recipient encoded in the valid leaf.
- Each holder can receive each round asset once. Onchain replay protection blocks double payouts.
- A holder or another relayer can submit the same proof directly if automated submission is unavailable. The submitting wallet pays that transaction’s gas.
- The strategy contract defines no claim deadline. Unclaimed assets remain in the strategy until a valid claim is submitted.
Integer division can leave small token residues after all nonzero entitlements are paid. The current strategy has no general admin rescue or dust-withdrawal function.
Failures and fallbacks
| Condition | Current behavior |
|---|---|
| Initial data is incomplete | The round is deferred. Missing samples are not interpolated. |
| Budget is below the minimum | No proposal is produced. Fees remain available for a later round. |
| A dynamic candidate fails before the snapshot is fixed | It is omitted before scoring for that round. If no valid dynamic assets remain, the round is deferred. |
| A pinned dynamic candidate fails later | Once the round’s universe snapshot is fixed, a missing required candidate causes the round to wait rather than silently changing its recorded inputs. |
| A fixed asset cannot execute | The entire round is deferred so its promised weight is not silently reassigned. |
| A purchase fails during execution | The leg can be retried during the open window. State changes revert if accounting or minimum-output checks fail. |
| Only some legs execute | After the deadline, completed legs become distributable and unspent paired asset returns to available strategy budget. |
| No legs execute | The expired round is cancelled and its reserved budget is released for a future proposal. |
| PONS requires its fee operator | Lore waits for the PONS-controlled conversion or sweep. Its keeper cannot impersonate that role. |
| Indexer or RPC data is unhealthy | The service fails closed and does not publish from incomplete or inconsistent history. |
| Keeper is offline or at capacity | Automated purchases or payouts can pause. Direct proof-based payout submission remains available once a round is distributable. |
Recipient capacity is also fail-closed. The current method commits every eligible launch-token holder into the payout tree. If the service cannot safely process the full holder set, it defers the round instead of silently omitting recipients.
What stays fixed
“Rule locked” refers to the recorded methodology hash and the strategy’s immutable contract fields. It does not mean that every future dynamic basket contains the same assets.
- Factory and acquisition adapter
- Issuer, initial publisher, and publisher gateway addresses
- Methodology hash, source mode, and basket rule
- Paired asset
- Earliest cycle interval
- Activation delay and execution window
- Maximum basket size and slippage
- Launch token and curve after binding
- Time-weighted holder set
- Observed wallet portfolios
- Dynamic assets and weights
- Eligible-universe additions
- Route availability and executable amount
- Creator-fee budget
- Recipients and payout weights
- Purchase amounts and execution timing
The publisher gateway has a narrow handover administrator until permanently locked. It cannot replace the vault code, withdraw funds, or make arbitrary calls. PONS remains an external dependency with its own administrative and operational controls.
Publisher handover
New vaults have a separate, immutable gateway in their publisher slot. The gateway accepts only basket proposals from its current authority and forwards them only to its bound vault. The initial publisher is recorded in the methodology and remains the handover administrator until locking, including after another publisher takes over.
- The administrator schedules a replacement address onchain. Every change starts a fresh 48-hour notice period. A pending change must be cancelled before a different one can be scheduled.
- The outgoing publisher may continue proposing during the notice period. Once the deadline arrives, new proposals stop until the handover is activated or cancelled.
- Anyone can activate the replacement after notice, once there is no active purchase cycle. Existing cycles must finish, or someone must finalize them after their execution deadline. Outstanding holder payouts do not prevent handover.
- The administrator may cancel a pending handover, including after its deadline. Cancellation restores the current publisher’s ability to propose.
- With no pending change, the administrator may permanently lock the current publisher. Locking clears the administrator and disables all future gateway handovers. It cannot be undone.
Handover leaves the vault address, fee destination, acquired assets, committed recipient roots, and existing payout rights unchanged. The replacement has the same proposal authority and remains subject to the vault’s timing, accounting, and execution checks. Each vault has its own gateway, so one handover does not change any other vault.
A future proof-verifying contract can occupy the publisher role, provided it can call this proposal interface. This release provides the handover path only. The pilot still relies on offchain indexing and publisher calculations, and a replacement contract must independently enforce its verification rules. Locking an EOA does not remove key trust. Locking an upgradeable or centrally controlled contract does not remove its internal controls.
The notice period provides visibility, with no holder vote or veto. A compromised administrator could schedule a malicious publisher or permanently lock an unwanted authority. Losing the administrator key can prevent migration; locking an unusable publisher can permanently stop new proposals. Historical vaults deployed with a direct immutable publisher have no handover path.
Each vault’s activity page shows its current publisher, gateway, pending change, earliest handover time, and lock status from an onchain read. Refresh it to check for updates. The gateway’s explorer link exposes the corresponding scheduled, cancelled, activated, and locked events.
Who does what
Chooses the rule and approves the launch or CTO plan.
Launches the token, records creator-fee routing, and handles the external CTO or voluntary handoff.
Creates one isolated strategy and fixes its contract-level rules.
Reconstructs finalized balances, observes portfolios, resolves the universe, and produces evidence artifacts. It does not sign transactions.
Checks the artifact, calculates minimum outputs, and submits the basket and payout commitment.
Enforces the current proposal authority and the 48-hour handover policy. The initial publisher administers changes until permanent locking.
Normally handles fee claims, purchases, expiry finalization, and proof-based payouts using a gas-funded wallet.
Holds creator-fee budget and acquired assets, enforces onchain timing and accounting, and transfers valid entitlements.
Reviews and appends technically compatible candidate assets and routes.
Lore starts in bootstrap mode. Our goal is trustless basket publication: anyone can submit a valid round, with proofs enforcing the rules instead of a trusted publisher’s approval. We aim to migrate as soon as that system is ready for safe deployment. The trust assumptions below apply until that migration is complete.
The current publisher’s calculations are not proven by the EVM. The gateway checks who may propose; the strategy records the submitted basket, recipient root, evidence hash, and purchase results. It does not independently reconstruct holder balances or portfolios. A dishonest publisher could submit a different contract-valid basket or recipient root, including one allocating acquired assets to itself. The purchase activation delay exposes the proposal before execution, but the current strategy has no governance vote or proposal cancellation function. Publisher handover does not cancel an already committed proposal.
The universe operator can append technically valid assets and routes after activation, making them eligible for dynamic plans without an address restriction. Hash-chained, append-only history makes additions visible and blocks silent removal or route replacement. It does not prove that a new asset is safe, valuable, or community-approved.
Fees and gas
The setup fee is paid on a new launch or when an existing strategy is activated. The operations portion is paid first. The remaining amount is reserved for a separate wallet’s deferred launch-token exposure. It cannot execute in the launch block. During the configured window, anyone may trigger the permissionless purchase, and acquired launch tokens go only to the fixed exposure beneficiary. Any native amount that cannot be spent can be released to that beneficiary after the deadline or curve graduation.
With the configured pilot split, 0.005 ETH goes to operations and 0.020 ETH funds the independent buyer’s later purchase. These are parts of the 0.025 ETH total, not additional fees. Neither the purchased tokens nor released reserve go to your launching wallet or your holders.
- Configured operations wallet
- 0x2De92833E835bf7C5aF493A0E09475E74EF6DcD1
- Configured independent buyer
- 0xdDeDE165E76F6dC63397c33c0E82eBdA6F764501
These are configured recipient addresses. The factory is live; the launch review checks the live fee split and recipients before signing.
An optional developer buy adds your chosen ETH budget to the launch total and sends purchased tokens to your launching wallet. It is separate from the mandatory independent buy reserve. See the launch guide for atomic execution and conversion slippage.
PONS launch fees, PONS protocol fees, market fees, price impact, and wallet gas are separate. The creator or community pays preparation, launch, activation and payout-setup transaction gas. ETH-funded plans allocate 10% of newly claimed creator fees to an operating reserve and 90% to purchases. The publisher and keeper need upfront native gas; the reserve does not guarantee a cadence or equal actual expenses. A holder pays gas only when choosing the manual payout fallback.
Verify a cycle
The Lore activity explorer supports each published round’s strategy, basket assets and weights, budget, evidence hash, recipient root, snapshot block and proof-backed claim interface. Round receipts also show indexed purchases, acquired amounts and payout progress when those records are available. A completed live pilot remains required; an implemented view does not establish completed payouts. Check the deployed factory and source records ↗
- Factory and strategy addresses
- Methodology hash and publisher
- Round budget and timing
- Assets, weights, and routes
- Purchase events and acquired amounts
- Recipient root and total weight
- Individual payout events
- Finalized block and timestamp
- Resolved universe version and candidates
- Aggregate evidence hash
- Ranked scores and compiled basket
- Recipient weights and proofs
- Code commit and manifest hash
An onchain hash shows which offchain result was committed and exposes later changes. Where the operator has published them, round pages link to evidence and audit bundles for reconstructing the result. Replay checks consistency of the supplied inputs; it does not independently establish the authenticity of historical source data. Missing or unavailable evidence is shown explicitly.
Current limits
- No independent Solidity, offchain-methodology, or economic audit has been published.
- No completed live Lore purchase and payout cycle is available yet.
- Dynamic admission requires fresh passing screens and complete observation coverage from the running shared-universe service. A token that is stale, quarantined or unsupported is excluded.
- Automatic execution depends on keeper capacity, gas funding, RPC access, PONS availability, and the local operator machine.
- There is no public automatic-payout service-level promise.
- Live-chain capacity, full-size payout, recovery, and production deployment drills remain release gates.
- An activated strategy follows its own recorded contract values and methodology hash. Shared-universe membership and service availability can change.
This page describes the current reviewed implementation. It is product documentation, not an audit, guarantee, or legal or financial assessment. See the Terms of Use for access restrictions and additional risk disclosures.
Terms used here
- Launch token
- The PONS token whose creator fees fund the strategy and whose holders receive the acquired assets.
- Creator fee
- The portion of PONS trading fees routed to the token’s configured creator-fee recipient.
- Paired asset
- The native or ERC-20 asset used as the token’s market pair and the strategy’s spending budget.
- Basket asset
- An eligible ERC-20 acquired during one round.
- Fixed basket
- A basket whose assets and target weights are recorded in the methodology before activation.
- Dynamic basket
- A basket whose membership or weights are recalculated from a holder or wallet source.
- TWAB
- Time-weighted average balance. Lore uses complete finalized samples across a set period.
- Finalized block
- A block the configured chain endpoint reports as finalized, used to reduce reorganization risk.
- Shared universe
- The append-only registry of technically admitted assets and acquisition routes dynamic plans may consider.
- Cycle or round
- One observation, proposal, purchase, and distribution sequence.
- Publisher
- The currently authorised address allowed to submit basket and recipient commitments through the vault’s gateway.
- Keeper
- A gas-funded automation service that normally calls permissionless contract functions for recurring onchain actions.
- Recipient root
- A Merkle commitment to the eligible holders and their payout weights for one round.
- Evidence hash
- A commitment to the finalized block, configuration, samples, portfolios, and universe data used to compile a round.