Collectibles V3 pack engine function reference
Every readable and writable function in AuroraCollectiblesPackEngineV3, with permissions, supply accounting and opening recovery.
ページです
Choose the correct version and address
This reference covers AuroraCollectiblesPackEngineV3, 3.0.0-collectibles-beta.1. V3 is the current factory build in Aurora; available networks depend on enabled deployments. Existing V2 collections remain V2 and V1 has no sealed packs. A website update does not upgrade an existing contract.
Read packEngine() on the collection and use that engine address for these actions. The engine reads collection.owner() for owner permissions. Never send clone actions to an implementation address.
Reads need no wallet transaction. Writes require gas and the permission shown below. Prices and quantities are integers; times on chain are Unix seconds, with zero meaning no opening start or deadline. Use Aurora transaction preparation for proofs and signed fee authorization.
What is permanent
- Collection and engine implementations, factory, provider, identities, lifetime caps and pool definitions cannot be replaced. A token belongs to one on-chain pool, but can appear in several organizational sets.
- Closing a phase or collection minting is permanent. Issued pack contents stay reserved and can still be delivered; configured opening windows still apply to new requests. Ownership renunciation is disabled.
- Pack slot pools, duplicate policy and transferability are fixed. Boxes contain card slots, not nested boosters. Consuming a wrapper does not restore its lifetime issuance capacity.
- V3 metadata can be corrected until each token is permanently frozen. Opening starts can change before issued packs gain access; existing deadlines can only be extended or removed. These permissions do not change balances, caps or chosen contents.
Supply, randomness and recovery
Lifetime minted + pooled + retired contents cannot exceed the token cap or configured collection cap. Wrapper supply is separate. Issuing a pack reserves its pool contents and provider capacity; only allocation identifies exact token IDs.
Openings progress through Requested, Seeded, Allocated and Opened. A request cannot be cancelled or rerolled. Allocation follows engine-wide request order; an earlier missing seed delays later allocation. Anyone may allocate the next seeded request, but only its original opener can choose the delivery recipient.
V3 allocateAndDeliver combines the last two stages. If the recipient rejects delivery, both allocation and delivery revert, preserving the seed and queue entry. Separate allocate followed by deliver remains available so a receiver problem need not block later allocation.
Opening gas and provider requirements depend on the configured adapter. The user-paid OpenVRF path submits the fixed proof in the collector wallet; the Chainlink adapter depends on its configured subscription. The final card-flip ceremony shows already confirmed contents and sends no extra transaction.
Readable functions
allowlistLeafRead only · allowlist helper
Computes the double-hashed leaf binding chain, engine, phase, payer, allowance and individual price. Proofs and wallet limits apply to the paying wallet, including gifts.
- 関数と論理を示した
allowlistLeaf(bytes32 phaseId, address wallet, uint256 allowance, uint256 price)- 返品・支払い
- bytes32
availableForSaleRead only · inventory bound
Returns remaining backed pack issuance capacity, or direct-item saleAvailable for content IDs. Does not apply phase timing, phase/wallet caps, allowlist proof or provider availability; use quote for purchase validation.
- 関数と論理を示した
availableForSale(uint256 id)- 返品・支払い
- uint256 available
collectionRead only · collection binding
The paired ERC-1155 collection address. Its owner controls this engine; its balances hold both cards and sealed packs.
- 関数と論理を示した
collection()- 返品・支払い
- address
factoryRead only · deployment binding
The immutable factory that created this implementation and initialized its clones.
- 関数と論理を示した
factory()- 返品・支払い
- address
getOpeningRead only · recoverable opening
Returns opener, pack ID, request nonce, fixed seed, state and selected IDs. States: 0 None, 1 Requested, 2 Seeded, 3 Allocated, 4 Opened. Repeated IDs represent duplicate copies.
- 関数と論理を示した
getOpening(bytes32 requestId)- 返品・支払い
- (address opener, uint256 packId, uint256 nonce, uint256 seed, uint8 state, uint256[] tokenIds)
getPackRead only · pack definition
Returns cap, lifetime issued, opening deadline, transferability, duplicate policy, existence and slot pools. V3 openingStartsAt is a separate getter.
- 関数と論理を示した
getPack(uint256 id)- 返品・支払い
- (uint256 maxSupply, uint256 issued, uint64 openingDeadline, bool transferable, bool duplicatesAllowed, bool exists, uint256[] slotPools)
getPhaseRead only · sale configuration
Returns sale configuration, cumulative minted units, configuration version, existence and permanent closure. Its packId field can identify a sealed pack or a directly sold collectible.
- 関数と論理を示した
getPhase(bytes32 phaseId)- 返品・支払い
- ((uint256 packId, uint64 startsAt, uint64 endsAt, uint256 unitPrice, uint256 supplyCap, uint256 walletCap, bytes32 allowlistRoot, address payoutRecipient, bool paused) config, uint256 minted, uint256 version, bool exists, bool closed)
getPoolRead only · pool inventory
Returns the draw model, remaining contents, committed contents, token entries and existence flag. Remaining weights describe the next draw, not a whole-pack probability.
- 関数と論理を示した
getPool(uint256 id)- 返品・支払い
- uint8 model, uint256 remaining, uint256 committed, (uint256 tokenId, uint128 remaining, uint64 weight)[] entries, bool exists
mintFeeAuthorityRead only · immutable
Returns the immutable factory that validates public-mint fee authorizations. It does not have owner or withdrawal powers.
- 関数と論理を示した
mintFeeAuthority()- 返品・支払い
- address
mintNonceRead only · replay protection
Payer-specific successful purchase nonce. A request must use its current value; another payer purchasing does not change it.
- 関数と論理を示した
mintNonce(address)- 返品・支払い
- uint256
mintedByWalletRead only · payer allowance usage
Cumulative units bought by a paying wallet in a phase, including gifts sent to other recipients.
- 関数と論理を示した
mintedByWallet(bytes32, address)- 返品・支払い
- uint256
nextAllocationNonceRead only · FIFO queue
The next sequence number eligible for allocation. An earlier request without a seed blocks later allocation.
- 関数と論理を示した
nextAllocationNonce()- 返品・支払い
- uint256
nextOpeningNonceRead only · FIFO queue
The next request sequence number. Requests are ordered globally within this engine, across pack types.
- 関数と論理を示した
nextOpeningNonce()- 返品・支払い
- uint256
openingAtRead only · opening lookup
Looks up a request ID by its engine sequence number.
- 関数と論理を示した
openingAt(uint256)- 返品・支払い
- bytes32
openingStartsAtRead only · V3 schedule
V3: earliest Unix-seconds time a pack can request opening. Zero means immediate. Does not change a request already made.
- 関数と論理を示した
openingStartsAt(uint256)- 返品・支払い
- uint64
quoteRead only · current-state estimate
Validates a proposed mint against current phase, version, supply, payer nonce and wallet rules and returns artwork unit and total prices. Another payer minting does not change this payer’s nonce. Does not include the platform fee or gas, reserve inventory, validate fee authorization, or guarantee a receiving contract accepts payment.
- 関数と論理を示した
quote((bytes32 phaseId, uint256 quantity, uint256 expectedVersion, uint256 nonce, uint256 maxUnitPrice, address recipient, uint256 allowance, uint256 allowlistPrice) request, address payer, bytes32[] proof)- 返品・支払い
- uint256 price, uint256 totalPrice
randomnessProviderRead only · immutable provider
The immutable provider adapter used by this engine or factory. Changing Aurora configuration cannot replace it for existing engines.
- 関数と論理を示した
randomnessProvider()- 返品・支払い
- address
tokenPoolRead only · pool membership
The permanent pool ID assigned to a content token. Releasing inventory does not clear this assignment; organizational sets are separate.
- 関数と論理を示した
tokenPool(uint256)- 返品・支払い
- uint256
Writable functions
allocateAnyone · next seeded request only
Allocates the next Seeded request in FIFO order from remaining pool inventory, records exact contents and advances the allocation queue. Cannot choose a seed or recipient. Useful if an opener receiver rejects delivery.
- 関数と論理を示した
allocate(bytes32 requestId)- 返品・支払い
- No return value
allocateAndDeliverOriginal opener · V3 only
V3: allocates the next Seeded request and delivers to the opener-chosen recipient in one transaction. Failed delivery rolls back allocation too, preserving the seed and request for retry or separate allocate/deliver.
- 関数と論理を示した
allocateAndDeliver(bytes32 requestId, address recipient)- 返品・支払い
- No return value
buyPackBuyer · payable, valid quote/proof/fee authorization required
Purchases 1–20 sealed packs or directly sold items, as selected by the phase. Exact native payment equals sale price plus signed platform fee. The recipient receives tokens; payer allowance and nonce are consumed. Failed payout or receiver callbacks revert the purchase.
- 関数と論理を示した
buyPack((bytes32 phaseId, uint256 quantity, uint256 expectedVersion, uint256 nonce, uint256 maxUnitPrice, address recipient, uint256 allowance, uint256 allowlistPrice) request, bytes32[] proof, uint256 fee, bytes authorization)- 返品・支払い
- No return value · PAYABLE
closePhaseCollection owner · ONE WAY
Permanently closes one sale and increments its version. Does not cancel issued packs or close the entire collection.
- 関数と論理を示した
closePhase(bytes32 phaseId)- 返品・支払い
- No return value
configurePackCollection owner · ONCE per pack ID
Creates a sealed wrapper with 1–20 pool slots, positive lifetime issuance cap, transferability and optional Unix-seconds opening deadline. Duplicate-free packs require distinct pools. Boxes use card slots, not nested packs.
- 関数と論理を示した
configurePack(uint256 packId, string tokenURI, uint256 maxSupply, bool transferable, uint64 openingDeadline, bool duplicatesAllowed, uint256[] slotPools)- 返品・支払い
- No return value
configurePhaseCollection owner · repeatable before phase closure
Creates or edits a sale for a configured pack or direct item. Cannot change the token ID of an existing phase or reopen a closed phase. Requires a nonzero direct payout recipient; version increments invalidate old quotes.
- 関数と論理を示した
configurePhase(bytes32 phaseId, (uint256 packId, uint64 startsAt, uint64 endsAt, uint256 unitPrice, uint256 supplyCap, uint256 walletCap, bytes32 allowlistRoot, address payoutRecipient, bool paused) config)- 返品・支払い
- No return value
configurePoolCollection owner · ONCE per pool ID
Creates an immutable pool with 1–128 entries. Model 0 draws among remaining copies; model 1 uses fixed positive weights for nonempty entries. Quantities fit uint128; weighted values fit uint64. Each token ID may belong to only one on-chain pool.
- 関数と論理を示した
configurePool(uint256 poolId, uint8 model, uint256[] tokenIds, uint256[] quantities, uint256[] weights)- 返品・支払い
- No return value
deliverOriginal opener only
Delivers an Allocated opening to the original opener chosen nonzero recipient. Burns the wrapper only on successful delivery. Retry with the same contents or a compatible recipient after receiver failure.
- 関数と論理を示した
deliver(bytes32 requestId, address recipient)- 返品・支払い
- No return value
extendOpeningDeadlineCollection owner · V3 only, extension/removal only
V3: extends an existing deadline or clears it with zero. Cannot shorten it or add expiry where none exists. Zero permanently removes the deadline.
- 関数と論理を示した
extendOpeningDeadline(uint256 id, uint64 next)- 返品・支払い
- No return value
fulfillRandomnessFixed randomness provider only
Saves the provider result only for a Requested opening. Zero is a valid seed. Does not allocate inventory or invoke token receivers.
- 関数と論理を示した
fulfillRandomness(bytes32 requestId, uint256 seed)- 返品・支払い
- No return value
initializeFactory only · ONCE
Binds the clone to its collection or engine during factory deployment. A second initialization or direct implementation initialization is rejected.
- 関数と論理を示した
initialize(address collection_)- 返品・支払い
- No return value
issuePackCollection owner · engine issuance
Issues 1–20 backed packs to a recipient, reserves pool contents and provider capacity, and mints sealed wrappers. Pack caps and expiry apply; no sale payment is collected.
- 関数と論理を示した
issuePack(uint256 packId, uint256 quantity, address recipient)- 返品・支払い
- No return value
releasePoolCollection owner · retirement is irreversible
Releases only uncommitted surplus while no opening awaits allocation. retire=true permanently removes capacity; false makes it available for direct minting. Pool membership and commitments remain protected.
- 関数と論理を示した
releasePool(uint256 poolId, uint256 entryIndex, uint256 quantity, bool retire)- 返品・支払い
- No return value
requestOpenPack holder · payable, one pack per request
Locks one held pack, records a permanent request in FIFO order and requests randomness from the fixed provider. Send the provider-required fee. Opening start/deadline rules apply. There is no cancel or reroll.
- 関数と論理を示した
requestOpen(uint256 packId)- 返品・支払い
- bytes32 requestId · PAYABLE
setOpeningStartsAtCollection owner · V3 only, restricted by issued access
V3: changes or clears the opening start before issued packs have gained opening access. Once issued packs can open, they cannot be locked again. A configured deadline must remain later than the start.
- 関数と論理を示した
setOpeningStartsAt(uint256 id, uint64 next)- 返品・支払い
- No return value
Sale requests and gift recipients
PhaseConfig.packId may name either a sealed pack or a direct collectible. Prices exclude the signed platform fee and gas. A zero phase or wallet cap means no limit at that level; actual inventory and lifetime caps still apply. A nonzero payoutRecipient receives the sale price immediately.
MintRequest binds phaseId, quantity, expectedVersion, payer nonce, maxUnitPrice, recipient, allowance and allowlistPrice. Gifts send tokens to recipient while the payer signs, pays and consumes its own phase allowance. buyPack also serves direct-item phases.
A quote does not reserve stock or authorize payment. Phase edits, expiry, inventory consumption, provider availability and receiver acceptance can still prevent a purchase. Metadata URIs are references, not proof that externally hosted content will remain unchanged.