一键导入
cartridge-vrng
Integrate Cartridge's verifiable random number generator (vRNG) into onchain games.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Integrate Cartridge's verifiable random number generator (vRNG) into onchain games.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Set up and manage Cartridge paymasters to sponsor transaction fees for gasless user experiences.
Configure Cartridge RPC endpoints with API token authentication and CORS whitelisting.
Interactively walk teams through creating a Cartridge Controller preset, including origin/AASA setup, session policies, themes, and mainnet vs sepolia configuration.
Integrate Cartridge Controller into React applications using starknet-react. Use when building React/Next.js web apps with Controller, setting up StarknetConfig provider, using hooks like useConnect/useAccount, or implementing wallet connection components. Covers ControllerConnector setup, provider configuration, and transaction execution patterns.
Configure session keys and policies for Cartridge Controller to enable gasless, pre-approved transactions. Use when defining contract interaction policies, setting spending limits, configuring signed message policies, or implementing error handling for session-based transactions. Covers SessionPolicies type, policy definitions, verified sessions, and error display modes.
Integrate Cartridge Controller wallet into Starknet applications. Use when setting up Controller for the first time, installing packages, configuring chains/RPC endpoints, or troubleshooting basic integration issues. Covers installation, Controller instantiation, ControllerConnector vs SessionConnector choice, chain configuration, and package compatibility.
| name | cartridge-vrng |
| description | Integrate Cartridge's verifiable random number generator (vRNG) into onchain games. |
Cartridge's Verifiable Random Number Generator provides cheap, atomic, verifiable randomness for onchain games. Randomness is generated and verified within a single transaction.
| Network | Address |
|---|---|
| Mainnet | 0x051fea4450da9d6aee758bdeba88b2f665bcbf549d2c61421aa724e9ac0ced8f |
| Sepolia | 0x051fea4450da9d6aee758bdeba88b2f665bcbf549d2c61421aa724e9ac0ced8f |
#[starknet::interface]
trait IVrfProvider<TContractState> {
fn request_random(self: @TContractState, caller: ContractAddress, source: Source);
fn consume_random(ref self: TContractState, source: Source) -> felt252;
}
#[derive(Drop, Copy, Clone, Serde)]
pub enum Source {
Nonce: ContractAddress,
Salt: felt252,
}
Source::Nonce(ContractAddress): Uses the address's internal nonce.
Each request generates a different seed.Source::Salt(felt252): Uses a provided salt.
Same salt = same random value.const VRF_PROVIDER_ADDRESS: starknet::ContractAddress =
starknet::contract_address_const::<0x051fea4450da9d6aee758bdeba88b2f665bcbf549d2c61421aa724e9ac0ced8f>();
fn roll_dice(ref self: ContractState) {
let vrf_provider = IVrfProviderDispatcher { contract_address: VRF_PROVIDER_ADDRESS };
let player_id = get_caller_address();
let random_value = vrf_provider.consume_random(Source::Nonce(player_id));
// Use random_value in game logic
}
request_random must be the first call in the multicall.
The Cartridge Paymaster wraps the multicall with submit_random and assert_consumed.
const call = await account.execute([
// First: request_random
{
contractAddress: VRF_PROVIDER_ADDRESS,
entrypoint: 'request_random',
calldata: CallData.compile({
caller: GAME_CONTRACT,
// Source::Nonce(address)
source: { type: 0, address: account.address },
// Or Source::Salt(felt252)
// source: { type: 1, salt: 0x123 },
}),
},
// Then: your game call
{
contractAddress: GAME_CONTRACT,
entrypoint: 'roll_dice',
// ...
},
]);
The source in request_random must match the source in consume_random.
Add the vRNG contract to your Controller policies:
const policies: Policy[] = [
// ... your existing policies ...
{
target: VRF_PROVIDER_ADDRESS,
method: "request_random",
description: "Allows requesting random numbers from the VRF provider",
},
];
Phase 0 assumes the Provider has not revealed the private key and does not collude with players. Future plans include moving the Provider to a Trusted Execution Environment (TEE).