MICA_PYBOBO_RL7GWQQ3D_1106
Date of notification
2025-11-6
Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.
The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.
Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 The utility token referred to in this white paper may not be exchangeable against the good or service promised in the crypto-asset white paper, especially in the case of a failure or discontinuation of the crypto-asset project.
Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.
Summary
Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 Warning: This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto- asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
Characteristics of the crypto-asset
The PYBOBO tokens referred to in this white paper are crypto-assets other than EMTs and ARTs, and are issued primarily on the TON blockchain. The maximum supply is 100 billion PYBOBO tokens. The PYBOBO Token Generation Event (TGE) opened on 18 November 2025. Where the white paper concerns a utility token, information about the quality and quantity of goods or services to which the utility tokens give access and restrictions on the transferability.Information about the quality and quantity of goods or services to which the utility tokens give access and restrictions on the transferability Since holding the crypto-asset does not guarantee any grant of access to any goods or services, this is not applicable.
Key information about the offer to the public or admission to trading Capybobo Limited is seeking admission for the token to trading on any Crypto-Asset Service Provider (CASP) platform in the European Union in accordance with Article 5 of REGULATION (EU) 2023/1114 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 31 May 2023 on markets in crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and (EU) 2019/1937. In accordance to Article 5(4), this crypto-asset white paper may be used by entities admitting the token to trading after Capybobo Limited as the person responsible for drawing up such white paper has given its consent to its use in writing to the respective Crypto Asset Service Provider. If a CASP wishes to use this white paper, inquiries can be made under [email protected].
Part A – Information about the offeror or the person seeking admission to trading
Name Capybobo Limited
Legal form BVI Limited Company
Registered address the office of the registered agent which is at Craigmuir Chambers, Road Town, Tortola, VG 1110, British Virgin Islands
Head office Not applicable
Registration date 1 Sep 2025
Legal entity identifier 254900265MUJKPX44O04
Another identifier required pursuant to applicable national law Capybobo Limited is registered in the British Virgin Islands under the number of 2185961
Contact telephone number Not Applicable
E-mail address [email protected]
Response time (Days) 030
Parent company Capybobo Foundation Company (A founderless Cayman Islands Foundation Company limited by guarantee)
Members of the management body
Name
Position
Address
RAMPAL, Ludovic Frederic Sebastien
Director
Craigmuir Chambers, Road Town, Tortola, VG 1110, British Virgin Islands
Business activity Capybobo Limited is a technical service provider and a token issuer, who is responsible for issuing of Capybobo Token, PYBOBO.
Parent company business activity Governance of the token
Newly established Capybobo Limited has been established since 2025 and is therefore newly established.
Financial condition for the past three years Not applicable
Financial condition since registr0ation Capybobo Limited and its parent company have not charged any revenue from the Token ecosystem. The company has financed issuance, marketing and listing preparations with initial private funding.
Part B – Information about the issuer, if different from the offeror or person seeking admission to trading
Issuer different from offeror or person seeking admission to trading No
Name Not Applicable
Legal form Not Applicable
Registered address Not Applicable
Head office Not Applicable
Registration date Not Applicable
Legal entity identifier Not Applicable
Another identifier required pursuant to applicable national law Not Applicable
Parent company Not Applicable
Members of the management body Not Applicable
Business activity Not Applicable
Parent company business activity Not Applicable
Part C – Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Name Not applicable
Legal form Not applicable
Registered address Not applicable
Head office Not applicable
Registration date Not applicable
Legal entity identifier Not applicable
Another identifier required pursuant to applicable national law Not applicable
Parent company Not applicable
Reason for crypto-Asset white paper Preparation Not applicable
Members of the Management body Not applicable
Operator business activity Not applicable
Parent company business activity Not applicable
Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Not applicable
Reason for drawing the white paper by persons referred to in Article 6(1) , second subparagraph, of Regulation (EU) 2023/1114 Not applicable
Part D – Information about the crypto-asset project
Crypto-asset project name Capybobo
Crypto-assets name PYBOBO Token
Abbreviation PYBOBO
Crypto-asset project description PYBOBO is a crypto-asset other than EMTs or ARTs, issued on the TON blockchain. Capybobo states that governance is conducted through “Capybobo Foundation,” Cayman Islands foundation company, issuance is conducted through “Capybobo Limited”; PYBOBO tokens are fungible and freely transferable. They confer no intrinsic economic, redemption or dividend rights. Tokenholder rights and governance procedures may be modified through proposals adopted by community vote under the Capybobo DAO Constitution when the voting mechanism is available. No representation is made that the tokens constitute, or are intended to constitute, an investment contract, security or other regulated financial instrument under applicable law.
Details of all natural or legal persons involved in the implementation of the crypto- asset project
Name
Role
Intro
Ludovic Rampal listed below is listed as “director of the CAPYBOBO Foundation” on the official website of the project
RAMPAL, Ludovic Frederic Sebastien
Director
This individual is identified as the leadership of Capybobo, the platform company that operates the marketplace and drives product and business development.
Utility Token Classification The token is classified as a utility token.
Key Features of Goods/Services for Utility Token Projects PYBOBO Token will be used for purchases of items within the Capybobo ecosystem.
Plans for the token No major tokenomic changes, or new functionality expansions beyond those disclosed in Section D.4 and D.7 are currently planned. Any future updates to token functionality or governance scope will be proposed and reviewed through community processes and disclosed via formal public channels when available.
Resource allocation To ensure transparency, issuer is making all CAPYBOBO accounts on TON chain in relation to the allocation of the tokens publicly available for the community to monitor.
Vesting:
airdrop 50%，TGE 4%，first month 4%, every 3 months 11.5% from 3rd month.
team 13%，TGE 0%，cliff12，vesting monthly over 1 year
treasury 20%，TGE 36%，vesting monthly over 3 years
ecosystem 12%, TGE 0%, vesting monthly over 30 months from first month
liquidity 5%，TGE 100%
Planned use of Collected funds or crypto-Assets
Not applicable, as this white paper was drawn up for the admission to trading and not for collecting funds for the crypto-asset-project.
Part E – Information about the offer to the public of crypto-assets or their admission to trading
Public offering or admission to trading The white paper concerns the admission to trading on any Crypto Asset Service Providers platform that has obtained the written consent of Capybobo Limited as the person drafting this white paper.
Reasons for public offer or admission to trading The purpose of the public offering is to distribute the PYBOBO token to enhance accessibility and enable secondary market activity under a transparent and compliant framework.
Fundraising target Not applicable
Minimum subscription goals Not applicable
Maximum subscription goals Not applicable
Oversubscription acceptance Not applicable
Oversubscription allocation Not applicable
Issue price Not applicable
Official currency or any other crypto-assets determining the issue price Not applicable, as this white paper is written to support admission to trading and not for the initial offer to the public.
Subscription fee Not applicable, as this white paper is written to support admission to trading and not for the initial offer to the public.
Offer price determination method Once the token is admitted to trading its price will be determined by demand (buyers) and supply (sellers).
Total number of offered/traded crypto-assets A total of 100,000,000,000 tokens will be minted and disclosed on the official website at TGE.
Targeted holders ALL
Holder restrictions The Holder restrictions are subject to the rules applicable to the Crypto Asset Service Provider as well as additional restrictions the Crypto Asset Service Providers might set in force.
Reimbursement notice Not applicable
Refund mechanism Not applicable
Refund timeline Not applicable
Offer phases Not applicable
Early purchase discount Not applicable
Time-limited offer Not applicable
Subscription period beginning Not applicable
Subscription period end Not applicable
Safeguarding arrangements for Offered Funds/Crypto-Assets Not applicable
Payment methods for crypto-asset purchase The payment methods are subject to the respective capabilities of the Crypto Asset Service Provider listing the crypto-asset.
Value transfer methods for reimbursement Not applicable
Right of withdrawal Not applicable, as this white paper is written to support admission to trading and not for the initial offer to the public.
Transfer of purchased crypto-assets The transfer of purchased crypto-assets are subject to the respective capabilities of the Crypto Asset Service Provider listing the crypto-asset.
Transfer time schedule Not applicable, as this white paper is written to support admission to trading and not for the initial offer to the public.
Purchaser's technical requirements The technical requirements that the purchaser is required to fulfil to hold the crypto- assets of purchased crypto-assets are subject to the respective capabilities of the Crypto Asset Service Provider listing the crypto-asset.
Crypto-asset service provider (CASP) name Not applicable
CASP identifier Not applicable
Placement form Not applicable
Trading platforms name The trading on all MiCAR-compliant trading platforms is sought.
Trading platforms Market identifier code (MIC) Not applicable
Trading platforms access This depends on the trading platform listing the asset.
Involved costs This depends on the trading platform listing the asset. Furthermore, costs may occur for making transfers out of the platform (i. e. "gas costs" for blockchain network use that may exceed the value of the crypto-asset itself).
Offer expenses Not applicable, as this crypto-asset white paper concerns the admission to trading and not the offer of the token to the public.
Conflicts of interest MiCAR-compliant Crypto Asset Service Providers shall have strong measurements in place in order to manage conflicts of interests. Due to the broad audience this white- paper is adressing, potential investors should always check the conflicts of Interest policy of their respective counterparty.
Applicable law Not applicable, as it is referred to on "offer to the public" and in this white-paper, the admission to trading is sought.
Competent court Not applicable, as it is referred to on "offer to the public" and in this white-paper, the admission to trading is sought.
Part F – Information about the crypto-assets
Crypto-asset type The crypto-asset described in the white paper is classified as a utility token under the Markets in Crypto-Assets Regulation (MiCAR) but does not qualify as an electronic money token (EMT) or an asset-referenced token (ART). It is a digital representation of value that can be stored and transferred using distributed ledger technology (DLT) or similar technology, without embodying or conferring any rights to its holder. The asset does not aim to maintain a stable value by referencing an official currency, a basket of assets, or any other underlying rights. Instead, its valuation is entirely market- driven, based on supply and demand dynamics, and not supported by a stabilization mechanism. It is neither pegged to any fiat currency nor backed by any external assets, distinguishing it clearly from EMTs and ARTs. Furthermore, the crypto-asset is not categorized as a financial instrument, deposit, insurance product, pension product, or any other regulated financial product under EU law. It does not grant financial rights, voting rights, or any contractual claims to its holders, ensuring that it remains outside the scope of regulatory frameworks applicable to traditional financial instruments.
Crypto-asset functionality PYBOBO is a governance and rewards token within the Capybobo ecosystem. It may be used for platform participation, governance voting, and earning rewards. While it provides access to certain features and incentives, it does not guarantee future value or benefits. PYBOBO does not confer any ownership rights, profit claims, or legal entitlements. Governance rights are procedural and executed on-chain, without affecting the issuer’s corporate control.
Planned application of functionalities Future functionalities of PYBOBO may include: -Access to DAO voting and grant proposal modules -Payment medium All future extensions are subject to governance proposals and will be disclosed through official channels. No additional financial rights or instruments will be attached to PYBOBO. A description of the characteristics of the crypto asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
Type of crypto-asset white paper The white paper type is "other crypto-assets" (i. e. "OTHR").
The type of submission The white paper submission type is "PYBOBO", which stands for new token.
Crypto-asset characteristics The tokens are crypto-assets other than EMTs and ARTs, which are available on the TON and bridged to, KAIA and BNB blockchains. The tokens are fungible (up to 9 digit after the decimal point), and a total of 100,000,000,000 will be issued. The tokens are a digital representation of value, and have no inherent rights attached as well as no intrinsic utility.
Commercial name or trading name See F.13.
Website of the issuer https://capybobo.io/
Starting date of offer to the public or admission to trading Starting date of admission to trading outside EU: TBD; Expected starting date of admission to trading within EU: TBD.
Publication date 6 November 2025
Any other services provided by the issuer No.
Identifier of operator of the trading platform No.
Language or languages of the crypto-asset white paper EN
Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available RL7GWQQ3D
Functionally fungible group digital token identifier, where available Not applicable
Voluntary data flag Mandatory.
Personal data flag The white paper does contain personal data.
LEI eligibility The issuer is eligible for a Legal Entity Identifier, LEI: 254900265MUJKPX44O04
Home Member State Ireland
Host Member States Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden. The three additional European Economic Area (EEA) countries (Iceland, Liechtenstein, and Norway), in addition to the EU member states, are being passported to.Part G – Information on the rights and obligations attached to the crypto-assets
Purchaser rights and obligations There are no rights or obligations attached for/of the purchaser
Exercise of rights and obligations As the token grants neither rights nor obligations, there are no procedures and conditions for the exercise of these rights applicable.
Conditions for modifications of rights and obligations As the token grants no legal binding rights nor obligations, there are no procedures and conditions for the exercise of these rights applicable. An adjustment of the technical infrastructure necessary to exercise the promised governance rights, declining functionality due to dilution, changing rights within the voting platforms, and all other adverse effects for investors may occur at any time.
Future public offers There are currently no planned future public offerings of PYBOBO. Any subsequent distributions or emissions will be subject to community governance or previously disclosed release schedules. Admission to trading on more compliant platforms is intended, but listing is not guaranteed at the time of this publication.
Issuer retained crypto-assets The issuer’s official resources, including the CAPYBOBO Foundation’s website, state that a significant portion of PYBOBO tokens are retained by the issuer for purposes such as ecosystem grants, community rewards, contributors, and strategic participants. As of the most recent update, the planned allocation reserves are disclosed as follow:
airdrop 50%
team 13%
treasury 20%
ecosystem 12%
liquidity 5% These allocations are intended but not technically fixed and may change through DAO governance. It must be noted that the assignment of specific addresses to the issuer or related entities cannot always be verified, and both the planned and actual distribution are subject to change at any time. The actual distribution may have a negative impact on the investor at any time.
Utility token classification Yes
Key features of goods/services of utility tokens The crypto-asset does not guarantee any grant of access to any goods or services. PYBOBO will be usable for purchases of items within the Capybobo ecosystem, such features are non-contractual and subject to change.
Utility tokens redemption Not applicable.
Non-trading request The admission to trading is sought.
Crypto-assets purchase or sale modalities Not applicable, as the admission to trading of the tokens is sought.
Crypto-assets transfer restrictions The crypto-assets as such do not have any transfer restrictions and are generally freely transferable. The Crypto Asset Service Providers can impose their own restrictions in agreements they enter with their clients. The Crypto Asset Service Providers may impose restrictions to buyers and sellers in accordance with applicable laws and internal policies and terms.
Supply adjustment protocols No.
Supply adjustment mechanisms No.
Token value protection schemes No, the token does not have value protection schemes.
Token value protection schemes description Not applicable
Compensation schemes No, the token does not have compensation schemes.
Compensation schemes description Not applicable
Applicable law Applicable law likely depends on the location of any particular transaction with the token.
Competent court Competent court likely depends on the location of any particular transaction with the token.
Part H – information on the underlying technology
Distributed ledger technology (DTL) Ledger type and visibility Public, permissionless blockchain (The Open Network, “TON”). Anyone can run a node, submit transactions, and verify the ledger. All PYBOBO transfers are publicly auditable. Core architecture Sharded design with three main layers: Masterchain: Holds global configuration, validator elections, and finality metadata. Workchains: Logical chains that can host different rule sets; PYBOBO is issued on the base workchain (typically workchain 0). Shardchains: Each workchain is split into shards for parallel processing. PYBOBO transactions are executed in the relevant shard(s) of workchain 0. Cross-shard messaging: Asynchronous message passing with cryptographic proofs ensures that PYBOBO transfers and contract calls can move safely across shards. Consensus and finality Proof-of-Stake (PoS) with Byzantine Fault Tolerant mechanics run by a set of elected validators staking TON. Blocks are produced continuously; finality is obtained after masterchain confirmation of the relevant shardchain blocks. Under normal conditions, confirmations complete within seconds to tens of seconds. Security holds as long as less than one-third of validator power is Byzantine; misbehavior can lead to slashing. Smart contracts and execution TON Virtual Machine (TVM) executes smart contracts represented as cells (Bag-of-Cells structure). Contracts are deterministic and gas-metered. PYBOBO uses the TON Jetton (TIP-3.x) fungible token standard: A Jetton master contract defines PYBOBO metadata, supply, and rules. Per-holder Jetton wallet contracts record balances and process transfers via internal messages. Contract addresses are derived from their initial state, enabling deterministic deployment and wallet discovery. Data model and storage State is stored as Merkle-like cell trees (Bag-of-Cells), enabling compact proofs and efficient verification. Storage “rent” applies to contracts holding persistent state. PYBOBO’s master and wallet contracts must maintain sufficient TON balance to remain active; otherwise, they can be frozen until topped up. Transaction processing and fees Every PYBOBO transfer is an internal message that consumes gas; fees depend on computation, storage usage, and message size. Replay protection and ordering are enforced by TVM semantics and contract logic. Failed deliveries can bounce, with refunds per protocol rules. Interoperability within TON Native interoperability across shards is guaranteed by the protocol’s messaging and proof system; no special trust assumptions are added for PYBOBO within TON. Any use of external bridges (to other chains) would rely on third-party protocols with separate trust and security models and is outside the base TON DLT. Security assumptions and risks (DLT-level) Dependent on validator decentralization and economic security of PoS staking. Public ledger implies pseudonymous transparency, no built-in privacy layer. Users must ensure their Jetton wallets keep enough TON for storage and transaction costs to avoid service disruption This DLT environment provides PYBOBO with high-throughput, sharded execution; fast probabilistic-to-economic finality; and standardized token behavior via Jetton contracts on the TON Virtual Machine.
Protocols and technical standard
1) Token standard: Jetton (TIP-3.x family)
Role: Defines the canonical fungible token pattern on TON.
Architecture:
Jetton master contract: Stores token metadata (name, symbol, decimals), total supply, mint/burn rules, admin privileges, and a reference to wallet code.
Jetton wallet contracts (per holder): Maintain balances and process transfers using internal messages; deterministically derived from the master + holder address.
Message opcodes (common subset; exact set depends on implementation):
Transfer: Sends tokens to another wallet; can carry a payload/comment and “forward_ton_amount” to fund the recipient wallet.
Mint/Burn: Admin-only or governed operations that adjust total supply.
Internal notifications: Jetton wallet-to-wallet and wallet-to-master receipts for successful/failed transfers (bounced messages).
Interface guarantees:
Standard method IDs and payload structure for interoperability across wallets, DEXes, and explorers.
Optional allowance/operator patterns depending on the chosen TIP-3.x variant.
2) Smart-contract languages and bytecode
TVM bytecode: Executed by the TON Virtual Machine (TVM).
Source languages:
FunC: High-level language compiled to TVM; commonly used for Jetton implementations.
Fift: Low-level stack language for scripts and specialized contracts.
Code and data layout:
Contracts packaged as Bag-of-Cells (B.o.C.) files. Initial state (code + data cells) deterministically defines the final on-chain address.
3) Messaging and transaction protocol (intra-chain)
Internal messages: Primary mechanism for smart-contract calls and token transfers; include value (TON for fees/rent), payload cells, and bounce flags.
Asynchronous execution: Transfers and callbacks happen across blocks/shards using message queues. Wallets must handle success and bounce paths.
Cross-shard correctness: Verified via Merkle proofs embedded in shard blocks and acknowledged in the masterchain.
4) Addressing and format standards
Workchain + account ID: 256-bit account hash plus workchain ID (e.g., 0 for base workchain).
User-friendly representation: Base64url with checksum and flags; raw hex form used by developers/tools.
Deterministic wallet derivation: Jetton wallet address = hash(master state + owner address + wallet code), enabling predictable discovery by wallets and explorers.
5) Metadata standards
On-chain key-value schema: Jetton standard supports a content cell with keys like name, symbol, decimals, description, image, and social links.
Off-chain metadata URI: Optional “content” can reference a JSON document hosted on HTTPS or IPFS; integrity can be anchored via content hash in-cell.
Encoding: UTF-8 for strings; image and file references should be content-addressed where possible.
6) Fee, gas, and storage standards
Gas metering: TVM charges for compute, storage reads/writes, and message size.
Storage rent: Contracts pay ongoing fees proportional to persistent state size. Jetton wallet design typically forwards a small TON amount during transfers to keep recipient wallets funded.
Replay/bounce handling: Standard Jetton patterns include nonces or state checks to avoid duplicate processing and define refunds on bounce.
7) Wallet and dApp integration standards
Wallet discovery: Given the master contract, wallets compute a user’s Jetton wallet address and query balance via get methods.
Transfer UX: Standard opcodes enable wallets to construct transfers with memo/comment fields and forward TON for rent.
DEX/aggregator compatibility: TIP-3.x message schemas are recognized by TON DEXes and payment apps; routers and vaults expect canonical transfer/burn/mint payloads.
8) Governance, admin, and upgradability conventions
Admin roles: sent to a burn address.
9) Node, client, and explorer interface
RPC and tooling: Interaction via TON API endpoints, lite-client, and community SDKs (TonWeb, ton.js, FunC/Fift toolchains).
Proof format: B.o.C.
Proofs for headers/transactions; light clients verify inclusion and state queries without full history.
Indexers/explorers: Standardized Jetton parsing enables supply and holder views; explorers read get methods and standard events.
10) Interoperability and bridges (non-native)
Inside TON: Cross-shard messaging is native; PYBOBO transfers are fully interoperable across shards with no extra trust assumptions.
Cross-chain: a bridge handled manually is enabled to bridge PYBOBO between TON and KAIA networks, the maximum supply of PYBOBO is always maintained at 100,000,000,000 PYBOBO.
Technology used Base blockchain (DLT) The Open Network (TON), a public, permissionless, Proof‑of‑Stake blockchain with sharded architecture (masterchain, workchains, shardchains). Smart contract runtime TON Virtual Machine (TVM) executes deterministic bytecode with gas metering. Contract code and state are stored in TON’s Bag‑of‑Cells (B.o.C.) data structure. Token standard Jetton (TIP‑3.x) fungible token standard. Architecture: one Jetton master contract (defines metadata, supply policy) and per‑holder Jetton wallet contracts (track balances, process transfers). Programming languages and build tools FunC for contract implementation (compiled to TVM bytecode). Fift for low‑level scripts, deployment, and debugging where needed. Toolchain: FunC compiler, Fift tools, and B.o.C. packers; optional use of toncli or similar build pipelines. Addressing and key cryptography Account addressing: 256‑bit account ID + workchain ID; user‑friendly base64url format with checksum. Cryptography: ED25519 for account keys and multisig controllers. Deterministic addressing for Jetton wallets derived from the master contract and owner address. Messaging and transaction layer Asynchronous internal message passing for transfers and contract calls. Standard Jetton opcodes for transfer, mint, burn, and receipts/bounce handling. Cross‑shard delivery secured via Merkle proofs acknowledged in the masterchain. Fees and storage Gas fees for compute, storage I/O, and message size. Storage “rent” for persistent contract state; transfers can include forward_ton_amount to fund recipient wallets’ rent. Metadata and data formats On‑chain metadata as key‑value cells or a “content” cell referencing off‑chain JSON (HTTPS/IPFS), optionally with content hash for integrity. UTF‑8 for strings; B.o.C. for proofs and artifacts. Node software and client interfaces TON validator/full node software for network participation and data availability. Light client and SDKs (e.g., tonweb, ton.js) for dApp/wallet integration. Explorers/indexers that implement Jetton parsing for balances, holders, and supply. Security and governance components Optional multisig admin contract (TVM multisig) to manage mint/burn/upgrade rights, if applicable. Audit and verification practices for Jetton master/wallet code; adherence to standard bounce/re‑entrancy handling patterns. Issuer‑specific fields to complete Jetton implementation/version: TIP‑3.X Master contract address (workchain): EQD-cvR0Nz6XAyRBvbhz-abTrRC6sI5tvHvvpeQraV9UAAD7 Decimals: 9 Maximum supply: 1,000,000,000 PYBOBO Admin/governance model (immutable/multisig/DAO): admin right has been sent to burn address: UQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJKZ
Consensus mechanism (TON)
Model
ProofofStake (PoS) with Byzantine Fault Tolerant (BFT) mechanics.
Validators stake TON, are elected, and collectively produce and validate blocks across the network’s shards.
Validator set and elections
Validators lock TON to participate. Elections and stake weights are coordinated via the masterchain.
The active validator set is periodically rotated based on staked amounts and protocol rules to maintain decentralization and liveness.
Sharded block production
TON is sharded: a masterchain plus multiple workchains, each split into shardchains.
Validators are assigned to specific shardchains for an epoch/round to produce blocks in parallel, increasing throughput.
Consensus protocol and finality
Blocks are proposed and validated using a PoS+BFT protocol. A block is considered finalized when its shardchain block is referenced and confirmed in the masterchain.
Under normal network conditions, confirmations occur within seconds to tens of seconds.
Safety holds as long as less than onethird of the validator voting power is Byzantine. Malicious validators risk slashing of their staked TON.
Crossshard correctness
TON uses asynchronous crossshard messaging with cryptographic proofs. Inclusion of shard proofs in the masterchain ensures ordered delivery and finality of crossshard transactions.
Economic incentives and penalties
Validators earn rewards (block rewards/fees) proportional to stake and performance.
Misbehavior (doublesigning, protocol violations) or prolonged downtime can lead to penalties and slashing, protecting the network against equivocation and censorship.
Implications for PYBOBO
PYBOBO token transfers and smartcontract calls inherit PoS security and finality from TON.
Finality is achieved once the relevant shardchain blocks are confirmed by the masterchain; after this, PYBOBO transactions are economically irreversible.
Liveness and throughput benefit from sharded block production, enabling high user concurrency for PYBOBO.
Risks and assumptions
Security depends on sufficient economic decentralization of the validator set.
Networkwide attacks would require controlling ≥1/3 of validator power to break safety; ≥2/3 to halt progress.
As a public blockchain, TON offers pseudonymous transparency; it does not provide builtin privacy for PYBOBO transactions.
Incentive mechanisms and applicable fees
Incentive mechanism (network-level, inherited by PYBOBO)
Validators (supply side) Stake TON to join the validator set and produce/validate blocks. Earn rewards from: - Block rewards (protocoldefined inflation, if active) and transaction fees. - Fees from storage rent collected on accounts/contracts. Face penalties/slashing for misbehavior (e.g., doublesigning) or downtime, aligning incentives toward honest participation.
Users and dApps (demand side) Pay fees in TON for executing transactions and storing state. Benefit from fast confirmation and high throughput, which encourages onchain PYBOBO utility
PYBOBO holders and integrators (token-level) PYBOBO itself is a Jetton (TIP3.x) and does not mint protocol rewards by default. Any additional incentives (e.g., liquidity mining, airdrops) are applicationspecific and must be disclosed by PYBOBO’s issuer or affiliated dApps. DEX liquidity providers earn trading fees; yield depends on the specific DEX (e.g., STON.fi) and pool parameters.
Applicable fees (what you actually pay)
TON gas (compute + bandwidth) Every PYBOBO operation is a TON transaction consuming gas for: -Compute steps executed in the TVM. - Message size (bytes) for internal messages. Gas is paid in TON (not in PYBOBO). Fees vary with message complexity and network conditions but are typically fractions of a TON.
Storage rent (state persistence) Contracts pay continuous rent proportional to their persistent state size. Jetton design forwards a small TON amount during transfers to ensure the recipient jetton wallet can cover rent (forward_ton_amount). If a wallet/contract becomes underfunded, it can be frozen and eventually pruned unless refilled.
Jetton transfer flow fees (TIP3.1 pattern) A standard token transfer triggers: - transfer from sender’s jetton wallet. - internal_transfer to recipient’s jetton wallet. - transfer_notification to the recipient address (or back to sender) plus excess refunds. Each hop consumes gas and may require attaching small TON amounts: - Fee for sender wallet execution. - Forwarded TON to fund recipient wallet execution and rent. - Tiny amount for notify message. Net effect: you’ll see multiple small TON debits and usually an “Excess” refund of unused TON back to the sender.
DEX and aggregator fees (if swapping PYBOBO) Liquidity pool swap fees (e.g., 0.3% or poolspecific), paid in the swapped asset. Routing/aggregator fees if using thirdparty routers. Usual TON gas and potential extra internal messages for multihop routes.
Bridge/oracle fees (if used) Crosschain bridges charge service fees and require onchain gas on both sides; these are thirdparty and not native to PYBOBO.
What the example transaction shows (from Tonviewer)
Actions: Jetton Transfer → Jetton Internal Transfer → Jetton Notify, with “Excess” refunds.
TON debits per step (illustrative from the page): ~0.0323 TON for internal transfer execution, 0.0001 TON for notify, Excess TON returned to the sender.
This is the standard cost profile of a TIP3.1 transfer: small TON amounts attached, then unused TON is refunded.
Bestpractice tips to minimize fees and rent risk
Keep a small TON balance in your wallet to fund gas and forward_ton_amount for token transfers.
When integrating PYBOBO in a dApp: Use canonical TIP3.1 payloads to ensure explorers/wallets can optimize gas and show refunds clearly. Rightsize forward_ton_amount: enough to execute and maintain recipient wallet rent, but not excessive. Batch operations where possible to reduce message overhead.
For highvolume transfers, monitor storage size of jetton wallets and clean up unused state if your implementation supports it.
Use of distributed ledger technology No, DLT is neither operated by the issuer nor a third party acting on the issuer’s behalf.
DLT functionality description Not applicable
Audit Audit has been performed.
Audit outcome Issues were identified and fully remediated prior to deployment.
Part I – Information on risks
1- Offer-related risks
Regulatory and Compliance This white paper has been prepared with utmost caution; however, uncertainties in the regulatory requirements and future changes in regulatory frameworks could potentially impact the token's legal status and its tradability. There is also a high probability that other laws will come into force, changing the rules for the trading of the token. Therefore, such developments shall be monitored and acted upon accordingly.
Operational and Technical Blockchain Dependency: The token is entirely dependent on the blockchain the crypto- asset is issued upon. Any issues, such as downtime, congestion, or security vulnerabilities within the blockchain, could adversely affect the token's functionality. Smart Contract Risks: Smart contracts governing the token may contain hidden vulnerabilities or bugs that could disrupt the token offering or distribution processes. Connection Dependency: As the trading of the token also involves other trading venues, technical risks such as downtime of the connection or faulty code are also possible. Human errors: Due to the irrevocability of blockchain-transactions, approving wrong transactions or using incorrect networks/addresses will most likely result in funds not being accessibly anymore. Custodial risk: When admitting the token to trading, the risk of losing clients assets due to hacks or other malicious acts is given. This is due to the fact the token is hold in custodial wallets for the customers.
Market and Liquidity Volatility: The token will most likely be subject to high volatility and market speculation. Price fluctuations could be significant, posing a risk of substantial losses to holders. Liquidity Risk: Liquidity is contingent upon trading activity levels on decentralized exchanges (DEXs) and potentially on centralized exchanges (CEXs), should they be involved. Low trading volumes may restrict the buying and selling capabilities of the tokens.
Counterparty As the admission to trading involves the connection to other trading venues, counterparty risks arise. These include, but are not limited to, the following risks: General Trading Platform Risk: The risk of trading platforms not operating to the highest standards is given. Examples like FTX show that especially in nascent industries, compliance and oversight-frameworks might not be fully established and/or enforced. Listing or Delisting Risks: The listing or delisting of the token is subject to the trading partners internal processes. Delisting of the token at the connected trading partners could harm or completely halt the ability to trade the token.
Liquidity Liquidity of the token can vary, especially when trading activity is limited. This could result in high slippage when trading a token.
Failure of one or more Counterparties Another risk stems from the internal operational processes of the counterparties used. As there is no specific oversight other than the typical due diligence check, it cannot be guaranteed that all counterparties adhere to the best market standards. Bankruptcy Risk: Counterparties could go bankrupt, possibly resulting in a total loss for the clients assets hold at that counterparty.
2- Issuer-related risks
Insolvency As with every other commercial endeavor, the risk of insolvency of the issuer is given. This could be caused by but is not limited to lack of interest from the public, lack of funding, incapacitation of key developers and project members, force majeure (including pandemics and wars) or lack of commercial success or prospects.
Counterparty In order to operate, the issuer has most likely engaged in different business relationships with one or more third parties on which it strongly depends on. Loss or changes in the leadership or key partners of the issuer and/or the respective counterparties can lead to disruptions, loss of trust, or project failure. This could result in a total loss of economic value for the crypto-asset holders.
Legal and Regulatory Compliance Cryptocurrencies and blockchain-based technologies are subject to evolving regulatory landscapes worldwide. Regulations vary across jurisdictions and may be subject to significant changes. Non-compliance can result in investigations, enforcement actions, penalties, fines, sanctions, or the prohibition of the trading of the crypto-asset impacting its viability and market acceptance. This could also result in the issuer to be subject to private litigation. The beforementioned would most likely also lead to changes with respect to trading of the crypto-asset that may negatively impact the value, legality, or functionality of the crypto-asset.
Operational Failure to develop or maintain effective internal control, or any difficulties encountered in the implementation of such controls, or their improvement could harm the issuer's business, causing disruptions, financial losses, or reputational damage.
Industry The issuer is and will be subject to all of the risks and uncertainties associated with a memecoin-project, where the token issued has zero intrinsic value. History has shown that most of this projects resulted in financial losses for the investors and were only set- up to enrich a few insiders with the money from retail investors.
Reputational The issuer faces the risk of negative publicity, whether due to, without limitation, operational failures, security breaches, or association with illicit activities, which can damage the issuer reputation and, by extension, the value and acceptance of the crypto-asset.
Competition There are numerous other crypto-asset projects in the same realm, which could have an effect on the crypto-asset in question.
Unanticipated Risk In addition to the risks included in this section, there might be other risks that cannot be foreseen. Additional risks may also materialize as unanticipated variations or combinations of the risks discussed.
3- Crypto-assets-related risks
Valuation As the crypto-asset does not have any intrinsic value, and grants neither rights nor obligations, the only mechanism to determine the price is supply and demand. Historically, most crypto-assets have dramatically lost value and were not a beneficial investment for the investors. Therefore, investing in these crypto-assets poses a high risk, and the loss of funds can occur.
Market Volatility Crypto-asset prices are highly susceptible to dramatic fluctuations influence by various factors, including market sentiment, regulatory changes, technological advancements, and macroeconomic conditions. These fluctuations can result in significant financial losses within short periods, making the market highly unpredictable and challenging for investors. This is especially true for crypto-assets without any intrinsic value, and investors should be prepared to lose the complete amount of money invested in the respective crypto-assets.
Liquidity ChallengesSome crypto-assets suffer from limited liquidity, which can present difficulties when executing large trades without significantly impacting market prices. This lack of liquidity can lead to substantial financial losses, particularly during periods of rapid market movements, when selling assets may become challenging or require accepting unfavorable prices.
Asset Security Crypto-assets face unique security threats, including the risk of theft from exchanges or digital wallets, loss of private keys, and potential failures of custodial services. Since crypto transactions are generally irreversible, a security breach or mismanagement can result in the permanent loss of assets, emphasizing the importance of strong security measures and practices.
Scams The irrevocability of transactions executed using blockchain infrastructure, as well as the pseudonymous nature of blockchain ecosystems, attracts scammers. Therefore, investors in crypto-assets must proceed with a high degree of caution when investing in if they invest in crypto-assets. Typical scams include – but are not limited to – the creation of fake crypto-assets with the same name, phishing on social networks or by email, fake giveaways/airdrops, identity theft, among others.
Blockchain Dependency Any issues with the blockchain used, such as network downtime, congestion, or security vulnerabilities, could disrupt the transfer, trading, or functionality of the crypto-asset.
Smart Contract Vulnerabilities The smart contract used to issue the crypto-asset could include bugs, coding errors, or vulnerabilities which could be exploited by malicious actors, potentially leading to asset loss, unauthorized data access, or unintended operational consequences.
Privacy ConcernsAll transactions on the blockchain are permanently recorded and publicly accessible, which can potentially expose user activities. Although addresses are pseudonoymous, the transparent and immutable nature of blockchain allows for advanced forensic analysis and intelligence gathering. This level of transparency can make it possible to link blockchain addresses to real-world identities over time, compromising user privacy.
Regulatory Uncertainty The regulatory environment surrounding crypto-assets is constantly evolving, which can directly impact their usage, valuation, and legal status. Changes in regulatory frameworks may introduce new requirements related to consumer protection, taxation, and anti-money laundering compliance, creating uncertainty and potential challenges for investors and businesses operating in the crypto space. Although the crypto-asset do not create or confer any contractual or other obligations on any party, certain regulators may nevertheless qualify the crypto-asset as a security or other financial instrument under their applicable law, which in turn would have drastic consequences for the crypto-asset, including the potential loss of the invested capital in the asset. Furthermore, this could lead to the sellers and its affiliates, directors, and officers being obliged to pay fines, including federal civil and criminal penalties, or make the crypto- asset illegal or impossible to use, buy, or sell in certain jurisdictions. On top of that, regulators could take action against the issuer as well as the trading platforms if the the regulators view the token as an unregistered offering of securities or the operations otherwise as a violation of existing law. Any of these outcomes would negatively affect the value and/or functionality of the crypot-asset and/or could cause a complete loss of funds of the invested money in the crypto-asset for the investor.
Counterparty risk Engaging in agreements or storing crypto-assets on exchanges introduces counterparty risks, including the failure of the other party to fulfill their obligations. Investors may face potential losses due to factors such as insolvency, regulatory non-compliance, or fraudulent activities by counterparties, highlighting the need for careful due diligence when engaging with third parties.
Reputational concerns Crypto-assets are often subject to reputational risks stemming from associations with illegal activities, high-profile security breaches, and technological failures. Such incidents can undermine trust in the broader ecosystem, negatively affecting investor confidence and market value, thereby hindering widespread adoption and acceptance.
Technological Innovation New technologies or platforms could render Solana's design less competitive or even break fundamental parts (i.e., quantum computing might break cryptographic algorithms used to secure the network), impacting adoption and value. Participants should approach the crypto-asset with a clear understanding of its speculative and volatile nature and be prepared to accept these risks and bear potential losses, which could include the complete loss of the asset's value.
Community and Narrative As the crypto-asset has no intrinsic value, all trading activity is based on the intended market value is heavily dependent on its community and the popularity of the memecoin narrative. Declining interest or negative sentiment could significantly impact the token’s value.
Interest Rate Change Historically, changes in interest, foreign exchange rates, and increases in volatility have increased credit and market risks and may also affect the value of the crypto-asset. Although historic data does not predict the future, potential investors should be aware that general movements in local and other factors may affect the market, and this could also affect market sentiment and, therefore most likely also the price of the crypto-asset.
Taxation The taxation regime that applies to the trading of the crypto-asset by individual holders or legal entities will depend on the holder’s jurisdiction. It is the holder’s sole responsibility to comply with all applicable tax laws, including, but not limited to, the reporting and payment of income tax, wealth tax, or similar taxes arising in connection with the appreciation and depreciation of the crypto-asset.
Anti-Money Laundering/Counter-Terrorism Financing It cannot be ruled out that crypto-asset wallet addresses interacting with the crypto-asset have been, or will be used for money laundering or terrorist financing purposes, or are identified with a person known to have committed such offenses.
Market Abuse It is noteworthy that crypto-assets are potentially prone to increased market abuse risks, as the underlying infrastructure could be used to exploit arbitrage opportunities through schemes such as front-running, spoofing, pump-and-dump, and fraud across different systems, platforms, or geographic locations. This is especially true for crypto-assets with a low market capitalization and few trading venues, and potential investors should be aware that this could lead to a total loss of the funds invested in the crypto-asset.
Timeline and Milestones Critical project milestones could be delayed by technical, operational, or market challenges.
4- Project implementation-related risks As this white paper relates to the "Admission to trading" of the crypto-asset, the implementation risk is referring to the risks on the Crypto Asset Service Providers side. These can be, but are not limited to, typical project management risks, such as key- personal-risks, timeline-risks, and technical implementation-risks.
5- Technology-related risks As this white paper relates to the "Admission to trading" of the crypto-asset, the technology-related risks mainly lie in the settling on the Solana-Network.
Blockchain Dependency Risks TON Network Downtime: Potential outages or congestion on the TON blockchain could interrupt on-chain token transfers, trading, and other functions. Scalability Challenges: Despite Solana's comparatively high throughput design, unexpected demand or technical issues might compromise its performance.
Smart Contract Risks Vulnerabilities: The smart contract governing the token could contain bugs or vulnerabilities that may be exploited, affecting token distribution or vesting schedules.
Wallet and Storage Risks Private Key Management: Token holders must securely manage their private keys and recovery phrases to prevent permanent loss of access to their tokens, which includes Trading-Venues, who are a prominent target for dedicated hacks. Compatibility Issues: The tokens require TON-compatible wallets for storage and transfer. Any incompatibility or technical issues with these wallets could impact token accessibility.
Network Security Risks Attack Risks: The TON blockchain may face threats such as denial-of-service (DoS) attacks or exploits targeting its consensus mechanism, which could compromise network integrity. Centralization Concerns: Although claiming to be decentralized, TON’s relatively smaller number of validators/concentration of stakes within the network compared to other blockchains and the influence of the TON Foundation might pose centralization risks, potentially affecting network resilience.
Evolving Technology Risks: Technological Obsolescence: The fast pace of innovation in blockchain technology may make TON token standard appear less competitive or become outdated, potentially impacting the usability or adoption of the token.
V.6.Mitigation measures None.
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
Adverse impacts on climate and other environment-related adverse impacts 1- Name Capybobo Limited
Relevant legal entity identifier 254900265MUJKPX44O04
Name of the crypto-asset PYBOBO
Consensus Mechanism (TON)
Model
ProofofStake (PoS) with Byzantine Fault Tolerance (BFT).
Validators lock TON to participate in block production and validation.
Validator elections and rotation
Stakes are placed and elections happen on the masterchain.
The active validator set is periodically rotated; voting power is proportional to stake.
Objective: decentralization, liveness, and resistance to capture.
Sharded architecture
TON consists of a masterchain and multiple workchains, each split into shardchains.
Validators are assigned to shardchains for epochs/rounds, producing blocks in parallel to scale throughput.
Block proposal, validation, and finality
Blocks are proposed and confirmed via a PoS+BFT protocol.
Finality: a shardchain block is economically finalized when it’s referenced and confirmed in the masterchain.
Typical confirmation times: seconds to tens of seconds, depending on network conditions.
Crossshard messaging
Asynchronous internal messages carry transactions between shards.
Inclusion of cryptographic proofs (Merkle proofs) in the masterchain ensures ordered, secure delivery across shards.
Incentives and slashing
Validators earn rewards from block rewards/fees and storage rent.
Misbehavior (e.g., doublesigning, censorship) or prolonged downtime can incur penalties or slashing of staked TON.
Security assumptions
Safety holds if less than onethird of validator power is Byzantine.
Liveness requires at least twothirds honest participation.
Economic security scales with the total value staked and validator decentralization.
Implications for PYBOBO
PYBOBO transfers and smartcontract calls inherit TON’s PoS security and finality.
Once included and confirmed in the masterchain, PYBOBO transactions are considered final.
High throughput and sharding support large holder counts and frequent transfers with low latency.
Incentive Mechanisms and Applicable Fees
Incentive mechanisms (network level, inherited by PYBOBO)
Validators
Stake TON to join the validator set and produce/validate blocks.
Earn: transaction fees, a share of protocol rewards (if/when defined), and portions of storage rent.
Face penalties/slashing for misbehavior or downtime, aligning incentives toward honest operation.
Users and dApps
Pay TON for gas and storage; benefit from fast finality and high throughput.
Activity (payments, swaps, transfers of PYBOBO) drives fee revenue to validators, sustaining the network.
Incentive mechanisms (PYBOBO token level)
Jetton standard
PYBOBO is a TIP3.x Jetton. The standard itself doesn’t pay yield to holders by default.
Any emissions, buybacks, staking, or liquidity mining are application/issuerdefined and should be disclosed by PYBOBO’s team if they exist.
Liquidity providers and integrators
DEX LPs (e.g., STON.fi pools) earn trading fees from swaps that include PYBOBO; APR depends on pool parameters and volume.
Market makers/routers may receive routing or performance fees per their integrations.
Applicable fees you’ll encounter
Gas (paid in TON)
Covers compute steps in TVM and message sizes.
Each PYBOBO transfer consists of multiple internal messages (transfer → internal_transfer → transfer_notification), each consuming gas.
Typical cost: small fractions of a TON per transfer; varies with payload size and network load.
Storage rent
Persistent state (jetton master and perholder wallet contracts) accrues rent over time.
Transfers usually include a small forward_ton_amount to the recipient wallet to cover execution and rent; unused TON is refunded as “Excess.”
DEX/trading fees (if swapping PYBOBO)
Pool fee (commonly around 0.3%, but poolspecific).
Possible aggregator/router fee for multihop routes.
Plus standard TON gas for each swap leg.
Bridge/oracle fees (if used)
Thirdparty bridges charge service fees and also require gas on both chains; risks and costs depend on the provider.
What the referenced transaction pattern shows
Tonviewer shows for PYBOBO transfers: Jetton Transfer → Jetton Internal Transfer → Jetton Notify, with small TON amounts for each step and “Excess” refunds.
Example lines you may see:
~0.03 TON for internal transfer execution,
~0.0001 TON for notify,
Excess TON returned to the sender after execution.
This is consistent with a standard TIP3.1 flow and cost structure.
Best practices to minimize costs and manage rent
Keep a small TON balance in your wallet to cover gas and forward_ton_amount for token transfers.
When integrating PYBOBO in a dApp:
Use the canonical TIP3.1 transfer layout to ensure compatibility and predictable refunds.
Rightsize forward_ton_amount so the recipient wallet remains rentcovered without overpaying.
Batch operations or use routers that minimize message hops.
Beginning of the period to which the disclosure relates 10 November 2025
End of the period to which the disclosure relates 10 November 2026
Energy consumption Estimated annual energy consumption: Low: 1 MWh / year Mid: 4 MWh / year High: 20 MWh / year Energy consumption sources and methodologies
Step 1 — Estimate TON network electricity use (E_TON)
E_TON = N_active × P_node_kW × hours × duty × PUE × M
N_active: average active validators over the period.
P_node_kW: average real power per validator node (include sentry/backup if not modeled separately).
hours: 24 × 365 for the reporting year.
duty: validator uptime (e.g., 0.95–1.00).
PUE: datacenter PUE (e.g., 1.2–1.6).
M: optional multiplier for additional nodes per validator (e.g., 1.0–2.0) if not embedded in P_node_kW.
Cross-check: Compare E_TON per validator to peer PoS chains and any available operator disclosures.
Step 2 — Allocate to PYBOBO
Preferred activity share: s_gas = (PYBOBO-related gas) / (total TON gas) for the same period.
Fallback: s_tx = (PYBOBO-tagged transactions) / (total TON transactions).
E_PYBOBO = s × E_TON, where s = s_gas when available, else s_tx.
Note: Document how PYBOBO-related gas/txs are identified (contract addresses, event signatures).
Sources
N_active: TON masterchain election snapshots; explorers (Tonviewer, tonapi).
P_node_kW: operator measurements, validator disclosures; vendor/server power under load; cloud instance power studies.
PUE: Uptime Institute, hyperscaler sustainability reports (region-specific where possible).
Activity share s: on-chain analytics/indexers with gas-by-contract; else explorer transaction counts.
Benchmarks: Academic/industry PoS energy assessments for plausibility bounds.
Output
Provide low/mid/high scenarios by varying N_active, P_node_kW, duty, PUE, and s within documented ranges.
State all assumptions, the exact 12month period, scope boundaries, and any exclusions (e.g., end-user devices, developer infrastructure).
Renewable energy consumption 27%
Energy intensity 0.00000 kWh
Scope 1 DLT GHG emissions – Controlled 0.00000 tCO2e/a
Scope 2 DLT GHG emissions – Purchased 0.01388 tCO2e/a
GHG intensity 0.00000 kgCO2e
Key energy sources and methodologies To determine the proportion of renewable energy usage, the locations of the nodes are to be determined using public information sites, open-source crawlers and crawlers developed in-house. If no information is available on the geographic distribution of the nodes, reference networks are used which are comparable in terms of their incentivization structure and consensus mechanism. This geo-information is merged with public information from Our World in Data, see citation. The intensity is calculated as the marginal energy cost wrt. one more transaction. Ember (2025); Energy Institute - Statistical Review of World Energy (2024) – with major processing by Our World in Data. “Share of electricity generated by renewables – Ember and Energy Institute” [dataset]. Ember, “Yearly Electricity Data Europe”; Ember, “Yearly Electricity Data”; Energy Institute, “Statistical Review of World Energy” [original data]. Retrieved from https://ourworldindata.org/grapher/share-electricity-renewables.
Key GHG sources and methodologies To determine the GHG Emissions, the locations of the nodes are to be determined using public information sites, open-source crawlers and crawlers developed in-house. If no information is available on the geographic distribution of the nodes, reference networks are used which are comparable in terms of their incentivization structure and consensus mechanism. This geo-information is merged with public information from Our World in Data, see citation. The intensity is calculated as the marginal emission wrt. one more transaction. Ember (2025); Energy Institute - Statistical Review of World Energy (2024) – with major processing by Our World in Data. “Carbon intensity of electricity generation – Ember and Energy Institute” [dataset]. Ember, “Yearly Electricity Data Europe”; Ember, “Yearly Electricity Data”; Energy Institute, “Statistical Review of World Energy” [original data]. Retrieved from https://ourworldindata.org/grapher/carbon-intensity-electricity. Licenced under CC BY 4.0.
Last updated