diff --git a/docs/AGENTS.md b/docs/AGENTS.md index e4c635ced..6c7a79130 100644 --- a/docs/AGENTS.md +++ b/docs/AGENTS.md @@ -49,7 +49,7 @@ npx skills add base/base-skills |apps:index |apps/builder-codes:agent-developers,app-developers,builder-codes,wallet-developers |apps/growth:rewards -|apps/guides:accept-b20-payments,migrate-to-standard-web-app +|apps/guides:accept-b20-payments,migrate-to-standard-web-app,verify-onchain |apps/quickstart:build-app,deploy-on-base |apps/resources:design-resources,templates |apps/technical-guides:base-notifications @@ -94,6 +94,8 @@ npx skills add base/base-skills |base-chain/specs/reference:configurability,glossary |base-chain/specs/upgrades/azul:exec-engine,node-upgrade,overview,proofs |base-chain/specs/upgrades/beryl:b20-playground,b20,overview +|base-chain/specs/upgrades/beryl/b20/specification:overview +|base-chain/specs/upgrades/beryl/b20/specification/concepts:architecture-and-precompiles,policies-and-scopes,roles-and-access-control,token-lifecycle,variants-asset-vs-stablecoin |base-chain/specs/upgrades/canyon:overview |base-chain/specs/upgrades/cobalt:eip-8130 |base-chain/specs/upgrades/delta:overview,span-batches diff --git a/docs/apps/guides/accept-b20-payments.mdx b/docs/apps/guides/accept-b20-payments.mdx index 88a14ac0e..7c20bc559 100644 --- a/docs/apps/guides/accept-b20-payments.mdx +++ b/docs/apps/guides/accept-b20-payments.mdx @@ -56,6 +56,6 @@ Call `publicClient.simulateContract` with the same arguments before sending. It ## Related pages -- [B20 token standard](/base-chain/specs/upgrades/beryl/b20): the full interface, including memos, policies, pausing, and roles. +- [B20 token standard](/base-chain/specs/upgrades/beryl/b20/specification/overview): the full interface, including memos, policies, pausing, and roles. - [Query B20 events](https://docs.cdp.coinbase.com/data/sql-api/b20-events): index `Transfer` and `Memo` events with the CDP SQL API to reconcile payments against orders at scale. - [Launch a B20 token](/get-started/launch-b20-token): create your own B20 token. \ No newline at end of file diff --git a/docs/base-chain/llms-full.txt b/docs/base-chain/llms-full.txt index ee157a89e..660a8fb58 100644 --- a/docs/base-chain/llms-full.txt +++ b/docs/base-chain/llms-full.txt @@ -17,6 +17,14 @@ ### Introduction - [Chain Overview](https://docs.base.org/base-chain/overview.md) — Entry point for Base Chain docs +### B20 Token Standard +- [B20 token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/overview.md) — Base-native ERC-20 superset implemented as Rust precompiles +- [Architecture & precompiles](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles.md) — Fixed precompiles, activation gates, and deterministic token addresses +- [Policies & scopes](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes.md) — Token policy slots, PolicyRegistry pointers, built-ins, and composite policies +- [Roles & access control](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control.md) — Built-in roles, user-defined role limits, and admin renunciation +- [Token lifecycle](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle.md) — Creation, initCalls, operation, memos, pausing, seizure, and admin renunciation +- [Variants: Asset vs Stablecoin](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin.md) — Variant choice, Asset extras, and Stablecoin currency + ### Core Concepts - [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering.md) — How blocks are ordered on Base - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality.md) — Detailed information about transaction finality on Base diff --git a/docs/base-chain/llms.txt b/docs/base-chain/llms.txt index 33e7a8237..4c231a379 100644 --- a/docs/base-chain/llms.txt +++ b/docs/base-chain/llms.txt @@ -7,6 +7,11 @@ ## Introduction - [Chain Overview](https://docs.base.org/base-chain/overview.md) — Start here for Base Chain docs, including concepts, network reference, node operation, APIs, and protocol specifications. +## B20 Token Standard +- [B20 token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/overview.md) — ERC-20-compatible native token standard with policy scopes, roles, memos, pausing, supply caps, and variants +- [Architecture & precompiles](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles.md) — Fixed precompiles, activation gates, and deterministic token addresses +- [Policies & scopes](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes.md) — How B20 token scopes point to PolicyRegistry policy IDs + ## Core Concepts - [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering.md) — How blocks are ordered on Base - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality.md) — Detailed information about transaction finality on Base diff --git a/docs/base-chain/specs/upgrades/beryl/b20-playground.mdx b/docs/base-chain/specs/upgrades/beryl/b20-playground.mdx index 88d70ca4d..f1a009ff5 100644 --- a/docs/base-chain/specs/upgrades/beryl/b20-playground.mdx +++ b/docs/base-chain/specs/upgrades/beryl/b20-playground.mdx @@ -16,7 +16,7 @@ B20 is a superset of ERC-20: every ERC-20 call works unchanged, so there's no co ## A compliance order arrives -A court order targets one account. Freeze it so it can't send, then seize the balance with one call. Seizure only works on an account that is already frozen. Every other holder is untouched and the token keeps trading. See [transfer policies](/base-chain/specs/upgrades/beryl/b20#policy-integration) and [burn](/base-chain/specs/upgrades/beryl/b20#burn) in the spec. +A court order targets one account. Freeze it so it can't send, then seize the balance with one call. Seizure only works on an account that is already frozen. Every other holder is untouched and the token keeps trading. See [transfer policies](/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes) and [freeze-and-seize](/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle#freeze-and-seize) in the docs. @@ -40,7 +40,7 @@ A new user shouldn't have to buy ETH first. With `permit`, they sign an approval ## The stock splits -A 2-for-1 split is one call. Every balance doubles without a migration or a new contract. Dividends run inside a public announcement window, so the disclosure lives onchain next to the action. The token also stores identifiers like a CUSIP. See the [Asset variant](/base-chain/specs/upgrades/beryl/b20#asset) in the spec. +A 2-for-1 split is one call. Every balance doubles without a migration or a new contract. Dividends run inside a public announcement window, so the disclosure lives onchain next to the action. The token also stores identifiers like a CUSIP. See the [Asset variant](/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin#asset-extras) in the spec. @@ -55,7 +55,7 @@ A 2-for-1 split is one call. Every balance doubles without a migration or a new Integration code for memo-tagged payments and B20-specific reverts. - + Every method, event, role, and policy in the standard. diff --git a/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles.mdx b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles.mdx new file mode 100644 index 000000000..fd9455800 --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles.mdx @@ -0,0 +1,53 @@ +--- +title: "Architecture & precompiles" +description: "Understand the B20 precompile architecture, fixed addresses, activation gates, and deterministic token addresses." +--- + +A B20 token is not a contract you deploy. It is a chain-native token surface implemented as a Rust precompile and created through the singleton B20 Factory. Solidity and offchain clients still call normal ABI methods, but there is no token bytecode to verify on an explorer. + +## System map + + +![B20 architecture swimlane: issuer or app calls the B20 Factory, the factory checks ActivationRegistry and creates a B20 token, and token operations consult PolicyRegistry.](/images/b20/b20-architecture-precompiles.png) + + +| Surface | Address | +|---|---| +| B20 Factory | `0xB20f000000000000000000000000000000000000` | +| ActivationRegistry | `0x8453000000000000000000000000000000000001` | +| PolicyRegistry | `0x8453000000000000000000000000000000000002` | + +These addresses are identical on every network where B20 is active. + +## Activation gates + +The ActivationRegistry is the chain-level feature flag surface. The factory checks activation before creating a token variant, and state-changing PolicyRegistry calls are activation-gated. + + +PolicyRegistry read functions are always callable. Integrations can safely call `isAuthorized`, `policyExists`, `policyAdmin`, and `pendingPolicyAdmin` without an activation write path. + + +## Address derivation + +B20 token addresses are deterministic and include the variant byte: + +```text +[10-byte B20 prefix][1-byte variant][9-byte keccak256(deployer, salt)] +``` + +You can identify a token's variant from the address without an RPC call by inspecting byte 10, zero-indexed: + +| Variant | Byte | Address shape | +|---|---:|---| +| Asset | `0x00` | `0xB200...` | +| Stablecoin | `0x01` | `0xB201...` | + +Use `IB20Factory.getB20Address(variant, deployer, salt)` to precompute the address and `isB20` / `isB20Initialized` to verify it. + +## What precompiles change for developers + +- Import interfaces from `base-std` instead of copying ABIs by hand. +- Use `StdPrecompiles` handles for the factory and registries. +- Do not expect explorer bytecode verification for token or registry addresses. +- Test with base-std mocks, `base-forge`, or `base-anvil` because stock EVM tooling does not know these precompiles by default. + diff --git a/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes.mdx b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes.mdx new file mode 100644 index 000000000..137906377 --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes.mdx @@ -0,0 +1,90 @@ +--- +title: "Policies & scopes" +description: "Learn how B20 policy scopes point to PolicyRegistry policies and gate transfers, mints, and seizures." +--- + +A B20 token chooses policies by scope. Each scope stores one `uint64` policy ID that points to a policy in the singleton PolicyRegistry. The token only checks the policy assigned to the relevant scope. + + +![B20 policies and scopes diagram: fixed token policy scopes store uint64 pointers to PolicyRegistry policies, and gated operations call isAuthorized before continuing or reverting.](/images/b20/b20-policies-and-scopes.png) + + +On a gated operation, the token reads the relevant scope, calls `PolicyRegistry.isAuthorized(policyId, account)`, and reverts with `PolicyForbids` or a seize-specific error when the policy result does not permit the action. + +## Policy scopes + +| Scope | Checked account | Gated operation | +|---|---|---| +| `TRANSFER_SENDER_POLICY` | `from` | `transfer`, `transferFrom`, and memo variants | +| `TRANSFER_RECEIVER_POLICY` | `to` | `transfer`, `transferFrom`, and memo variants | +| `TRANSFER_EXECUTOR_POLICY` | `msg.sender` | `transferFrom` only when `msg.sender != from` | +| `MINT_RECEIVER_POLICY` | `to` | `mint` and `mintWithMemo` | +| `SEIZE_HOLDER_POLICY` | `from` | `seizeWithMemo`; the holder is seizable only when not authorized by this policy | + +`approve` and `permit` are not policy-gated. Only balance movement is checked. + + +Every scope defaults to `ALWAYS_ALLOW` (`0`) at creation. An unattended B20 deployment is fully open, and no account is seizable until `SEIZE_HOLDER_POLICY` is intentionally configured. + + +## Policy types + +| Type | Behavior | +|---|---| +| `BLOCKLIST` | Accounts are authorized by default; listed accounts are denied. | +| `ALLOWLIST` | Accounts are denied by default; listed accounts are authorized. | +| `UNION` | Composite policy: account is authorized if any child policy authorizes it. | +| `INTERSECT` | Composite policy: account is authorized only if every child policy authorizes it. | + +Composite policies combine existing simple `ALLOWLIST` and `BLOCKLIST` policies. Child policies must be simple policies, not other composites or built-ins. + +## Built-ins and ID anatomy + +Policy IDs are `uint64` values. The top byte is the `PolicyType`; the low 56 bits are a global counter. Counters `0` and `1` are reserved for built-ins, and custom policy creation starts at counter `2`. + +| Constant | ID | Behavior | +|---|---:|---| +| `ALWAYS_ALLOW` | `0` | Authorizes every account. Default value for every scope. | +| `ALWAYS_BLOCK` | `(uint64(ALLOWLIST) << 56) \| 1` | Denies every account. | + + +`isAuthorized` never reverts on a non-existent policy ID. Malformed or uncreated IDs collapse to empty-set semantics: `ALLOWLIST` denies and `BLOCKLIST` allows. Validate `policyExists(policyId)` before binding a token scope. + + +```solidity +uint64 policyId = 0x0100000000000002; +require(StdPrecompiles.POLICY_REGISTRY.policyExists(policyId), "policy missing"); +IB20(token).updatePolicy(B20Constants.MINT_RECEIVER_POLICY, policyId); +``` + +## Registry administration + +Each policy has one admin. The current admin can: + +- Update allowlist, blocklist, or composite membership. +- Stage a two-step admin transfer with `stageUpdateAdmin`. +- Permanently renounce policy administration with `renounceAdmin`. + + +`renounceAdmin(policyId)` freezes the policy forever. Membership and child-policy updates become impossible. + + +## Read a token's configured policies + +```solidity +bytes32[5] memory scopes = [ + B20Constants.TRANSFER_SENDER_POLICY, + B20Constants.TRANSFER_RECEIVER_POLICY, + B20Constants.TRANSFER_EXECUTOR_POLICY, + B20Constants.MINT_RECEIVER_POLICY, + B20Constants.SEIZE_HOLDER_POLICY +]; + +for (uint256 i; i < scopes.length; i++) { + uint64 id = IB20(token).policyId(scopes[i]); + bool exists = id == 0 || id == ((uint64(uint8(IPolicyRegistry.PolicyType.ALLOWLIST)) << 56) | 1) + || StdPrecompiles.POLICY_REGISTRY.policyExists(id); + require(exists, "scope points to missing policy"); +} +``` + diff --git a/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control.mdx b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control.mdx new file mode 100644 index 000000000..9651970c6 --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control.mdx @@ -0,0 +1,63 @@ +--- +title: "Roles & access control" +description: "Understand B20 roles, access-control gates, user-defined roles, and irreversible admin renunciation." +--- + +B20 is an ERC-20 superset with built-in role-based access control. Its role API uses familiar admin, grant, revoke, and renounce patterns, but B20 only enforces the built-in roles listed here. + +## Base roles + +| Role | Gates | +|---|---| +| `DEFAULT_ADMIN_ROLE` | Role grants/revokes, `setRoleAdmin`, `updatePolicy`, `updateSupplyCap` | +| `MINT_ROLE` | `mint`, `mintWithMemo` | +| `BURN_ROLE` | `burn`, `burnWithMemo` | +| `BURN_BLOCKED_ROLE` | Deprecated back-compat `burnBlocked` implementation only | +| `SEIZE_ROLE` | `seizeWithMemo` | +| `PAUSE_ROLE` | `pause` | +| `UNPAUSE_ROLE` | `unpause` | +| `METADATA_ROLE` | `updateName`, `updateSymbol`, `updateContractURI` | +| `OPERATOR_ROLE` | Asset-only multiplier and announcement operations | + + +User-defined roles have no built-in enforcement. You can create them with `setRoleAdmin` and grant them with `grantRole`, but B20 token functions only check the built-in roles. + + +## Admin renunciation + +B20 has a specific last-admin rule. The last `DEFAULT_ADMIN_ROLE` holder cannot renounce or be revoked through normal role methods; those calls revert with `LastAdminCannotRenounce`. + +Use `renounceLastAdmin()` to permanently move the token to an admin-less state. A token can also launch admin-less by passing `initialAdmin == address(0)` at creation. + +After admin renunciation: + +- `DEFAULT_ADMIN_ROLE`-gated operations are permanently uncallable. +- Existing operational role grants continue to work. +- Admin resurrection is blocked; `grantRole`, `revokeRole`, and `setRoleAdmin` revert even through custom admin-role chains. + +## Pre-renunciation checklist + +Configure every surviving operational path before renouncing the last admin. + +```solidity +IB20 token = IB20(tokenAddress); + +// 1. Grant roles that must survive admin renunciation. +token.grantRole(B20Constants.MINT_ROLE, issuerOps); +token.grantRole(B20Constants.PAUSE_ROLE, incidentResponder); +token.grantRole(B20Constants.UNPAUSE_ROLE, governanceSafe); +token.grantRole(B20Constants.SEIZE_ROLE, complianceSafe); + +// 2. Bind policies and supply cap while DEFAULT_ADMIN_ROLE still exists. +token.updatePolicy(B20Constants.MINT_RECEIVER_POLICY, mintAllowlistPolicyId); +token.updatePolicy(B20Constants.SEIZE_HOLDER_POLICY, seizeHolderPolicyId); +token.updateSupplyCap(1_000_000e18); + +// 3. Permanently remove token administration. +token.renounceLastAdmin(); +``` + + +For an admin-less launch from creation, put the required grants and policy updates in `initCalls`, then set `initialAdmin` to `address(0)` in the create params. + + diff --git a/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle.mdx b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle.mdx new file mode 100644 index 000000000..042adf71c --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle.mdx @@ -0,0 +1,102 @@ +--- +title: "Token lifecycle" +description: "Follow a B20 token from factory creation through initCalls, operation, pausing, memos, seizures, and admin renunciation." +--- + +A B20 token moves through four practical phases: create, bootstrap, operate, and optionally renounce administration. + +## Create + +All B20 tokens are created through the singleton factory: + +```solidity +address token = StdPrecompiles.B20_FACTORY.createB20(variant, salt, params, initCalls); +``` + +- `variant` is `ASSET` or `STABLECOIN`. +- `salt` contributes to deterministic address derivation. +- `params` are versioned by a leading byte and encoded with `B20FactoryLib`. +- `initCalls` are ABI-encoded calls that run on the new token before the factory returns. + +The factory reverts with `FeatureNotActivated` if the requested token variant is not active on the chain. + +## Bootstrap with initCalls + +During the creation transaction, factory-originated initCalls bypass token role gates and transfer-side policy gates. This lets you configure policy scopes, grant roles, set caps, and seed balances atomically. + +The bypass is deliberately limited: + +- `MINT_RECEIVER_POLICY` is always enforced, including during initCalls. +- Pause state is never bypassed. +- Token invariants such as supply cap and balance accounting are never bypassed. + + +If you start the token paused, put `pause(...)` late in the initCalls array so earlier bootstrap operations are not blocked by your own pause. + + +## Operate + +Common issuer operations include: + +- Minting with `MINT_ROLE`, subject to `MINT_RECEIVER_POLICY` and `supplyCap`. +- Burning from the caller with `BURN_ROLE`. +- Seizing with `SEIZE_ROLE` through `seizeWithMemo` when the holder is denied by `SEIZE_HOLDER_POLICY`. +- Pausing `TRANSFER`, `MINT`, `BURN`, or `SEIZE` independently. +- Updating name, symbol, and contract URI with `METADATA_ROLE`. + +The `PausableFeature` enum is append-only. Integrators should handle unknown future values defensively when switch-casing over returned pause data. + +## Freeze and seize + +`seizeWithMemo` transfers a holder's balance to a destination in one admin operation. It skips allowance and transfer policies; its membership check is `SEIZE_HOLDER_POLICY`. + +```solidity +// Configure this policy so denied accounts are eligible for seizure. +token.updatePolicy(B20Constants.SEIZE_HOLDER_POLICY, seizeHolderPolicyId); + +// Later, an authorized operator seizes from a holder denied by SEIZE_HOLDER_POLICY. +vm.prank(complianceOperator); +token.seizeWithMemo(holder, destination, amount, bytes32("case-2026-08")); +``` + +The transaction emits `Transfer`, `Memo`, and `Seized` in order. + +## Pause and unpause + +```solidity +IB20.PausableFeature[] memory features = new IB20.PausableFeature[](2); +features[0] = IB20.PausableFeature.TRANSFER; +features[1] = IB20.PausableFeature.SEIZE; + +token.pause(features); // requires PAUSE_ROLE +token.unpause(features); // requires UNPAUSE_ROLE +``` + +Paused operations revert with `ContractPaused(feature)`. + +## Memos + +Memos are `bytes32` payloads emitted immediately after the primary event of a memo-enabled operation. + +Memo entrypoints: + +- `transferWithMemo` +- `transferFromWithMemo` +- `mintWithMemo` +- `burnWithMemo` +- `seizeWithMemo` + +Indexers join a `Memo` log to the operation it annotates with `(transactionHash, logIndex - 1)`. + +```ts +const memoLogs = parseEventLogs({ abi, logs: receipt.logs, eventName: 'Memo' }); +for (const memoLog of memoLogs) { + const parentLog = receipt.logs[memoLog.logIndex - 1]; + console.log({ memo: memoLog.args.memo, parentTopic0: parentLog.topics[0] }); +} +``` + +## Admin renunciation + +If an issuer wants an admin-less token, it must grant surviving operational roles, bind required policies, and set the supply cap before calling `renounceLastAdmin()`. After renunciation, admin-gated configuration cannot be restored. + diff --git a/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin.mdx b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin.mdx new file mode 100644 index 000000000..704479e84 --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin.mdx @@ -0,0 +1,54 @@ +--- +title: "Variants: Asset vs Stablecoin" +description: "Choose between B20 Asset and Stablecoin variants and understand their variant-specific behavior." +--- + +B20 has two variants. Both share the base ERC-20-compatible B20 surface, roles, policy scopes, memos, pausing, supply caps, and permit. + +## Decision table + +| Capability | Asset | Stablecoin | +|---|---|---| +| Decimals | Configurable 6-18 at creation | Fixed `6` | +| Variant byte | `0x00` | `0x01` | +| Address shape | `0xB200...` | `0xB201...` | +| Extra metadata | Yes | No | +| Scaled balance multiplier | Yes | No | +| Announcements | Yes | No | +| Batch mint | Yes | No | +| Currency code | No | Yes | + +## Asset extras + +### Multiplier + +Asset tokens expose a WAD-precision multiplier for scaled UI balances. Raw balances remain unchanged; scaled balances are derived at read time. + + +For Asset tokens, `balanceOf(account)` returns the raw ERC-20 balance. `scaledBalanceOf(account)` returns the multiplier-adjusted display balance. Choose one view for your integration and label it clearly. + + +Routine multiplier changes should use scheduled updates when possible. Instant `updateMultiplier` is an emergency override. + +### Announcements + +`announce(internalCalls, id, description, uri)` emits `Announcement`, executes internal calls, then emits `EndAnnouncement`. Announcement IDs are unique forever. Non-panic inner reverts are wrapped in `InternalCallFailed`. + +Use announcements to wrap holder-impacting operations such as batch minting or multiplier changes. + +### Batch mint + +`batchMint(recipients, amounts)` mints to multiple recipients atomically. Any failing element reverts the whole batch. It is gated by `MINT_ROLE` and should be wrapped in `announce` when disclosure is required. + +### Extra metadata + +Asset tokens can store issuer-defined string key/value metadata. Setting an empty value deletes the entry. + +## Stablecoin currency + +Stablecoin tokens expose `currency()`, set once at creation. The code must contain uppercase `A`-`Z` characters only. + + +B20 validates the currency code format, not the issuer's claim. A token can set `currency()` to `USD`, but B20 does not verify reserves, legal status, or registration with an external currency registry. + + diff --git a/docs/base-chain/specs/upgrades/beryl/b20/specification/overview.mdx b/docs/base-chain/specs/upgrades/beryl/b20/specification/overview.mdx new file mode 100644 index 000000000..3f84f55c6 --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/b20/specification/overview.mdx @@ -0,0 +1,35 @@ +--- +title: "B20 token standard" +description: "Build with Base-native B20 tokens: ERC-20 compatible precompile tokens with roles, policy scopes, memos, supply caps, pausing, and variants." +--- + +B20 is Base's native token standard: an ERC-20 superset implemented as Rust precompiles. Standard ERC-20 calls such as `transfer`, `transferFrom`, `approve`, `balanceOf`, and `allowance` work unchanged, so existing wallets, indexers, and app integrations can treat a B20 token like an ERC-20 token. + +B20 adds issuer-grade controls at the chain level: policy-gated transfers and mints, role-based administration, granular pausing, supply caps, memos, ERC-2612 `permit`, and variant-specific features for assets and stablecoins. + +## Choose your path + + + + Create a B20 token with the factory and mint the first supply. + + + Learn how token policy scopes point to PolicyRegistry entries. + + + +## Variants + +| Variant | Decimals | Address byte | Use when | +|---|---:|---:|---| +| Asset | 6-18, configured at creation | `0x00` | You need asset features such as scaled balances, announcements, batch minting, or extra metadata. | +| Stablecoin | Fixed `6` | `0x01` | You need a fixed-decimal token with a self-declared currency code. | + +## Learn the model + +- [Architecture & precompiles](/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles): why B20 is configured through fixed precompile surfaces instead of deployed bytecode. +- [Policies & scopes](/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes): how token scopes point to registry policies and gate operations. +- [Roles & access control](/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control): who can mint, pause, seize, change metadata, and renounce administration. +- [Token lifecycle](/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle): how creation, initCalls, operation, and admin renunciation fit together. +- [Variants: Asset vs Stablecoin](/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin): how to choose a token variant. + diff --git a/docs/base-chain/specs/upgrades/beryl/overview.mdx b/docs/base-chain/specs/upgrades/beryl/overview.mdx index 3ff77e873..acfd51117 100644 --- a/docs/base-chain/specs/upgrades/beryl/overview.mdx +++ b/docs/base-chain/specs/upgrades/beryl/overview.mdx @@ -5,10 +5,10 @@ description: "Overview of the Beryl hardfork, introducing the B20 native token s ## Summary -- Introduce [B20](/base-chain/specs/upgrades/beryl/b20): Base's native token standard for stablecoin, real-world asset (RWA), and long-tail token issuers +- Introduce [B20](/base-chain/specs/upgrades/beryl/b20/specification/overview): Base's native token standard for stablecoin, real-world asset (RWA), and long-tail token issuers - Reduce the single-proof withdrawal finalization period from 7 days to 5 days for increased capital efficiency - Reth V2: up to 50% disk reduction and a rewritten state root pipeline delivering +33% throughput -- Upcoming in a later Beryl phase: [native account abstraction (EIP-8130)](/base-chain/specs/upgrades/beryl/eip-8130), currently previewing on the vibenet devnet +- Upcoming in a later Beryl phase: native account abstraction (EIP-8130), currently previewing on the vibenet devnet ## Activation Timestamps @@ -33,19 +33,19 @@ Action required before activation. Upgrade to the required version before each n B20 is Base's native token standard - ERC-20 compatible tokens implemented as Rust precompiles, designed for stablecoin, real-world asset, and long-tail token issuers. -- [B20 Overview](/base-chain/specs/upgrades/beryl/b20) -- [Roles Model](/base-chain/specs/upgrades/beryl/b20#roles-model) -- [Policy Integration](/base-chain/specs/upgrades/beryl/b20#policy-integration) -- [Factory](/base-chain/specs/upgrades/beryl/b20#factory) -- [Policy Registry](/base-chain/specs/upgrades/beryl/b20#policy-registry) -- [Mint & Burn](/base-chain/specs/upgrades/beryl/b20#mint) -- [Variants](/base-chain/specs/upgrades/beryl/b20#variants) +- [B20 Overview](/base-chain/specs/upgrades/beryl/b20/specification/overview) +- [Roles & access control](/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control) +- [Policy Integration](/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes) +- [Factory](/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles) +- [Policy Registry](/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes) +- [Token lifecycle](/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle) +- [Variants](/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin) ## Native Account Abstraction (EIP-8130) A later Beryl phase brings account abstraction into the protocol. Accounts configure authorized actors and signature validation onchain. Apps get portable smart accounts, scoped session keys, atomic batching, and native gas sponsorship without bundler or relay infrastructure. EIP-8130 is experimental and currently runs only on the vibenet devnet. -- [Native Account Abstraction (EIP-8130)](/base-chain/specs/upgrades/beryl/eip-8130) +- Native Account Abstraction (EIP-8130): planned for a later Beryl phase ## Withdrawals diff --git a/docs/docs.json b/docs/docs.json index f6ddd67f2..6508f5e7c 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -9,14 +9,21 @@ }, "favicon": "/logo/favicon.png", "contextual": { - "options": ["copy", "view", "claude", "chatgpt"] + "options": [ + "copy", + "view", + "claude", + "chatgpt" + ] }, "api": { "playground": { "display": "simple" }, "examples": { - "languages": ["javascript"] + "languages": [ + "javascript" + ] } }, "seo": { @@ -32,7 +39,9 @@ "groups": [ { "group": "Introduction", - "pages": ["get-started/base"] + "pages": [ + "get-started/base" + ] }, { "group": "Quickstart", @@ -269,8 +278,23 @@ "group": "Beryl", "pages": [ "base-chain/specs/upgrades/beryl/overview", - "base-chain/specs/upgrades/beryl/b20" - + { + "group": "B20", + "pages": [ + "base-chain/specs/upgrades/beryl/b20/specification/overview", + "get-started/launch-b20-token", + { + "group": "Concepts", + "pages": [ + "base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles", + "base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes", + "base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control", + "base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle", + "base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin" + ] + } + ] + } ] }, { @@ -410,7 +434,9 @@ "groups": [ { "group": "Introduction", - "pages": ["base-account/overview/what-is-base-account"] + "pages": [ + "base-account/overview/what-is-base-account" + ] }, { "group": "Quickstart", @@ -646,7 +672,9 @@ "groups": [ { "group": "Overview", - "pages": ["ledgers/overview"] + "pages": [ + "ledgers/overview" + ] }, { "group": "Ledgers", @@ -679,7 +707,9 @@ }, { "group": "Growth", - "pages": ["apps/growth/rewards"] + "pages": [ + "apps/growth/rewards" + ] }, { "group": "Builder Codes", @@ -697,11 +727,15 @@ "groups": [ { "group": "Overview", - "pages": ["agents/index"] + "pages": [ + "agents/index" + ] }, { "group": "Quickstart", - "pages": ["agents/quickstart"] + "pages": [ + "agents/quickstart" + ] }, { "group": "Guides", @@ -3256,6 +3290,10 @@ { "source": "/ai-agents/:slug*", "destination": "/agents/:slug*" + }, + { + "source": "/base-chain/specs/upgrades/beryl/b20/concepts/*", + "destination": "/base-chain/specs/upgrades/beryl/b20/specification/concepts/*" } ], "integrations": { diff --git a/docs/get-started/launch-b20-token.mdx b/docs/get-started/launch-b20-token.mdx index 2dc6adbce..f010bd142 100644 --- a/docs/get-started/launch-b20-token.mdx +++ b/docs/get-started/launch-b20-token.mdx @@ -327,4 +327,5 @@ All without writing, deploying, or auditing a token contract. ## Next steps * [Accept B20 payments in an app](/apps/guides/accept-b20-payments): wire this token into a checkout flow that tags each payment with an order ID and reconciles it from onchain events. -* Gate transfers or mints with PolicyRegistry policies, add granular pause, or manage roles. See the [B20 token standard](/base-chain/specs/upgrades/beryl/b20). \ No newline at end of file +* Your token currently allows every transfer, by everyone, to anyone. That is a choice, not an accident — [learn how B20 policies work](/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes) to change it. +* Learn the full model in the [B20 token standard](/base-chain/specs/upgrades/beryl/b20/specification/overview). \ No newline at end of file diff --git a/docs/images/b20/b20-architecture-precompiles.png b/docs/images/b20/b20-architecture-precompiles.png new file mode 100644 index 000000000..3c66e5963 Binary files /dev/null and b/docs/images/b20/b20-architecture-precompiles.png differ diff --git a/docs/images/b20/b20-policies-and-scopes.png b/docs/images/b20/b20-policies-and-scopes.png new file mode 100644 index 000000000..65bedad4b Binary files /dev/null and b/docs/images/b20/b20-policies-and-scopes.png differ diff --git a/docs/llms-full.txt b/docs/llms-full.txt index a1c8c522f..2b21795d8 100644 --- a/docs/llms-full.txt +++ b/docs/llms-full.txt @@ -102,7 +102,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Static Docs Files](https://docs.base.org/get-started/docs-llms): Use llms.txt and llms-full.txt to give AI assistants access to Base documentation. - [MCP Server](https://docs.base.org/get-started/docs-mcp): Connect your AI coding assistant to Base documentation using Model Context Protocol for real-time access. - [Get Funded](https://docs.base.org/get-started/get-funded): The Base ecosystem offers multiple funding pathways designed specifically for builders at every stage—from weekend experiments to full-scale ventures. -- [Launch a B20 Token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base by calling the B20 Factory precompile. +- [Launch a B20 token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base with one call to the B20 Factory precompile, with roles, supply caps, and compliance controls built in. - [Launch a Token](https://docs.base.org/get-started/launch-token) - [Learning Resources](https://docs.base.org/get-started/learning-resources): Find educational content for learning Solidity, Ethereum, and blockchain development - [Developer's Guide to Effective AI Prompting](https://docs.base.org/get-started/prompt-library): Learn practical AI prompting techniques to enhance your coding workflow and get better results from AI coding assistants. @@ -116,6 +116,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Overview](https://docs.base.org/base-chain/specs/protocol/overview): High-level overview of the Base Chain protocol, covering rollup architecture, core components, and user flows for deposits, transactions, and withdrawals. - [Proofs](https://docs.base.org/base-chain/specs/protocol/proofs/index): Overview of the offchain services and onchain contracts that make L2 checkpoint proposals verifiable from Ethereum in the Azul proof system. - [Overview](https://docs.base.org/base-chain/specs/upgrades/azul/overview): Overview of the Azul hardfork, introducing Osaka EVM support, a simplified execution client, and a multi-proof system for L2 checkpoints. +- [B20 token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/overview): Build with Base-native B20 tokens: ERC-20 compatible precompile tokens with roles, policy scopes, memos, supply caps, pausing, and variants. - [Overview](https://docs.base.org/base-chain/specs/upgrades/beryl/overview): Overview of the Beryl hardfork, introducing the B20 native token standard, reduced withdrawal delays, and Reth V2. - [Canyon](https://docs.base.org/base-chain/specs/upgrades/canyon/overview): Overview of the Canyon hardfork, bringing Ethereum Shanghai EIPs (EIP-3651, EIP-3855, EIP-3860) to the Base execution layer. - [Delta](https://docs.base.org/base-chain/specs/upgrades/delta/overview): Overview of the Delta hardfork, introducing span batches to reduce L1 data costs by compressing multiple L2 blocks into single batcher transactions. @@ -206,7 +207,13 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Execution Engine](https://docs.base.org/base-chain/specs/upgrades/azul/exec-engine): Execution engine changes in the Azul hardfork, including the EIP-7825 transaction gas limit cap and secp256r1 precompile cost updates. - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul. - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security. -- [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 native token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): Learn how B20, Base's native token standard, serves stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 playground](https://docs.base.org/base-chain/specs/upgrades/beryl/b20-playground): Try B20's issuer flows in your browser: freeze-and-seize, payment memos, gasless approvals, and onchain corporate actions on Base. +- [Architecture & precompiles](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles): Understand the B20 precompile architecture, fixed addresses, activation gates, and deterministic token addresses. +- [Policies & scopes](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes): Learn how B20 policy scopes point to PolicyRegistry policies and gate transfers, mints, and seizures. +- [Roles & access control](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control): Understand B20 roles, access-control gates, user-defined roles, and irreversible admin renunciation. +- [Token lifecycle](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle): Follow a B20 token from factory creation through initCalls, operation, pausing, memos, seizures, and admin renunciation. +- [Variants: Asset vs Stablecoin](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin): Choose between B20 Asset and Stablecoin variants and understand their variant-specific behavior. - [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays. - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting. - [Derivation](https://docs.base.org/base-chain/specs/upgrades/ecotone/derivation): Derivation changes in the Ecotone upgrade, extending the retrieval stage to support EIP-4844 blobs as an additional data availability source. @@ -369,6 +376,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Rewards](https://docs.base.org/apps/growth/rewards): Earn financial incentives for building high-quality Apps that drive user engagement and onchain transactions - [Accept B20 payments](https://docs.base.org/apps/guides/accept-b20-payments): Accept B20 token payments in your app and match each transaction to an order with onchain memos. - [Migrate to a Standard Web App](https://docs.base.org/apps/guides/migrate-to-standard-web-app): Migrate your Farcaster mini-app to work in the Base App. Covers replacing deprecated SDK methods, and registering on Base.dev. +- [Verify Users Onchain](https://docs.base.org/apps/guides/verify-onchain): Enforce Sybil resistance and policy gating inside any Base contract. Base Verify signs a short-lived verification your contract checks in the same transaction as a claim, deposit, or vote, so one real identity counts once and only wallets that meet your bar can participate. - [Build an app on Base](https://docs.base.org/apps/quickstart/build-app): A step-by-step guide to building a Next.js tally app on Base using wagmi and viem, with wallet connection, contract reads and writes, and batch transaction support. - [Deploy on Base](https://docs.base.org/apps/quickstart/deploy-on-base): Deploy a smart contract to Base Sepolia with Foundry. - [Add notifications](https://docs.base.org/apps/technical-guides/base-notifications): Send in-app notifications to your app's users through the Base Dashboard REST API. diff --git a/docs/llms.txt b/docs/llms.txt index 679a7cfb5..e4c8e0931 100644 --- a/docs/llms.txt +++ b/docs/llms.txt @@ -14,7 +14,7 @@ - [Static Docs Files](https://docs.base.org/get-started/docs-llms): Use llms.txt and llms-full.txt to give AI assistants access to Base documentation. - [MCP Server](https://docs.base.org/get-started/docs-mcp): Connect your AI coding assistant to Base documentation using Model Context Protocol for real-time access. - [Get Funded](https://docs.base.org/get-started/get-funded): The Base ecosystem offers multiple funding pathways designed specifically for builders at every stage—from weekend experiments to full-scale ventures. -- [Launch a B20 Token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base by calling the B20 Factory precompile. +- [Launch a B20 token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base with one call to the B20 Factory precompile, with roles, supply caps, and compliance controls built in. - [Launch a Token](https://docs.base.org/get-started/launch-token) - [Learning Resources](https://docs.base.org/get-started/learning-resources): Find educational content for learning Solidity, Ethereum, and blockchain development - [Developer's Guide to Effective AI Prompting](https://docs.base.org/get-started/prompt-library): Learn practical AI prompting techniques to enhance your coding workflow and get better results from AI coding assistants. @@ -28,6 +28,7 @@ - [Overview](https://docs.base.org/base-chain/specs/protocol/overview): High-level overview of the Base Chain protocol, covering rollup architecture, core components, and user flows for deposits, transactions, and withdrawals. - [Proofs](https://docs.base.org/base-chain/specs/protocol/proofs/index): Overview of the offchain services and onchain contracts that make L2 checkpoint proposals verifiable from Ethereum in the Azul proof system. - [Overview](https://docs.base.org/base-chain/specs/upgrades/azul/overview): Overview of the Azul hardfork, introducing Osaka EVM support, a simplified execution client, and a multi-proof system for L2 checkpoints. +- [B20 token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/overview): Build with Base-native B20 tokens: ERC-20 compatible precompile tokens with roles, policy scopes, memos, supply caps, pausing, and variants. - [Overview](https://docs.base.org/base-chain/specs/upgrades/beryl/overview): Overview of the Beryl hardfork, introducing the B20 native token standard, reduced withdrawal delays, and Reth V2. - [Canyon](https://docs.base.org/base-chain/specs/upgrades/canyon/overview): Overview of the Canyon hardfork, bringing Ethereum Shanghai EIPs (EIP-3651, EIP-3855, EIP-3860) to the Base execution layer. - [Delta](https://docs.base.org/base-chain/specs/upgrades/delta/overview): Overview of the Delta hardfork, introducing span batches to reduce L1 data costs by compressing multiple L2 blocks into single batcher transactions. @@ -84,7 +85,7 @@ - [Network Fees](https://docs.base.org/base-chain/network-information/network-fees): Documentation about network fees on Base. This page covers details of the two-component cost system involving L2 execution fees and L1 security fees, and offers insights on fee variations and cost-saving strategies. - [Throughput and Limits](https://docs.base.org/base-chain/network-information/throughput-and-limits): Gas limits and throughput-related network parameters on Base. - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality): Detailed information about transaction finality on Base. -- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): This page outlines how Base transactions are ordered. +- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): Transactions are ordered based priority fee and arrival time, which determines which Flashblock they are included in. - [Troubleshooting Transactions](https://docs.base.org/base-chain/network-information/troubleshooting-transactions): Guide to diagnosing and resolving transaction issues on Base. - [Node Providers](https://docs.base.org/base-chain/node-operators/node-providers): Documentation for Node Providers for the Base network. Including details on their services, supported networks, and pricing plans. - [Node Performance](https://docs.base.org/base-chain/node-operators/performance-tuning): Hardware specifications, storage requirements, client recommendations, and configuration settings for running a performant Base node. @@ -118,7 +119,13 @@ - [Execution Engine](https://docs.base.org/base-chain/specs/upgrades/azul/exec-engine): Execution engine changes in the Azul hardfork, including the EIP-7825 transaction gas limit cap and secp256r1 precompile cost updates. - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul. - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security. -- [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 native token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): Learn how B20, Base's native token standard, serves stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 playground](https://docs.base.org/base-chain/specs/upgrades/beryl/b20-playground): Try B20's issuer flows in your browser: freeze-and-seize, payment memos, gasless approvals, and onchain corporate actions on Base. +- [Architecture & precompiles](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/architecture-and-precompiles): Understand the B20 precompile architecture, fixed addresses, activation gates, and deterministic token addresses. +- [Policies & scopes](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/policies-and-scopes): Learn how B20 policy scopes point to PolicyRegistry policies and gate transfers, mints, and seizures. +- [Roles & access control](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/roles-and-access-control): Understand B20 roles, access-control gates, user-defined roles, and irreversible admin renunciation. +- [Token lifecycle](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/token-lifecycle): Follow a B20 token from factory creation through initCalls, operation, pausing, memos, seizures, and admin renunciation. +- [Variants: Asset vs Stablecoin](https://docs.base.org/base-chain/specs/upgrades/beryl/b20/specification/concepts/variants-asset-vs-stablecoin): Choose between B20 Asset and Stablecoin variants and understand their variant-specific behavior. - [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays. - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting. - [Derivation](https://docs.base.org/base-chain/specs/upgrades/ecotone/derivation): Derivation changes in the Ecotone upgrade, extending the retrieval stage to support EIP-4844 blobs as an additional data availability source. @@ -281,6 +288,7 @@ - [Rewards](https://docs.base.org/apps/growth/rewards): Earn financial incentives for building high-quality Apps that drive user engagement and onchain transactions - [Accept B20 payments](https://docs.base.org/apps/guides/accept-b20-payments): Accept B20 token payments in your app and match each transaction to an order with onchain memos. - [Migrate to a Standard Web App](https://docs.base.org/apps/guides/migrate-to-standard-web-app): Migrate your Farcaster mini-app to work in the Base App. Covers replacing deprecated SDK methods, and registering on Base.dev. +- [Verify Users Onchain](https://docs.base.org/apps/guides/verify-onchain): Enforce Sybil resistance and policy gating inside any Base contract. Base Verify signs a short-lived verification your contract checks in the same transaction as a claim, deposit, or vote, so one real identity counts once and only wallets that meet your bar can participate. - [Build an app on Base](https://docs.base.org/apps/quickstart/build-app): A step-by-step guide to building a Next.js tally app on Base using wagmi and viem, with wallet connection, contract reads and writes, and batch transaction support. - [Deploy on Base](https://docs.base.org/apps/quickstart/deploy-on-base): Deploy a smart contract to Base Sepolia with Foundry. - [Add notifications](https://docs.base.org/apps/technical-guides/base-notifications): Send in-app notifications to your app's users through the Base Dashboard REST API.