Credible Finance

DeFi · Real World Assets

Token Transparency Filing

B2 v2.1 · Filed 27 Jul 2026Partial - 1 gap

Project & Team

Description of Project

A narrative description of the purpose of the project is provided.

Credible is the Open Payment Stack, payment rails for businesses traditional providers won't serve. Gaming, prediction markets, creator platforms, and fintechs use Credible to collect payments locally across emerging markets and settle globally in stablecoins, same day. Credible acts as merchant of record, underwrites risk with AI, and advances instant settlement from its own float, one integration, no 7-day delays.

$CRED is the network's ownership token, launched via community raise on MetaDAO.

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Labs / DevCo

Full Name	Official Title	Prior Experience
Shrikant Bhalereao	Founder and CEO	Before Credible, we built a healthcare fintech, Kiwimoney, that exited to Anq. Shri has spent 14+ years in payments. He’s worked on card acquiring and issuing at Gemalto (acquired by Thales), payment orchestration at CellPoint Digital, global commerce at Anatwine (acquired by Zalando), enterprise infrastructure at Oracle, and crypto-backed credit at Nexo.
Akshay Soam	Founder and CTO	Akshay has spent 10+ years across fintech, gaming, and payments at YooZoo Games and HSBC. Before that, he got his Master’s in AI/ML from Liverpool John Moores University.

Foundation

Full Name	Official Title	Prior Experience
Shrikant Bhalerao	Contributor	Before Credible, we built a healthcare fintech, Kiwimoney, that exited to Anq. Shri has spent 14+ years in payments. He’s worked on card acquiring and issuing at Gemalto (acquired by Thales), payment orchestration at CellPoint Digital, global commerce at Anatwine (acquired by Zalando), enterprise infrastructure at Oracle, and crypto-backed credit at Nexo.

DAO / Onchain Governance

Full Name	Official Title	Prior Experience
Shrikant Bhalerao	Contributor	Before Credible, we built a healthcare fintech, Kiwimoney, that exited to Anq. Shri has spent 14+ years in payments. He’s worked on card acquiring and issuing at Gemalto (acquired by Thales), payment orchestration at CellPoint Digital, global commerce at Anatwine (acquired by Zalando), enterprise infrastructure at Oracle, and crypto-backed credit at Nexo.

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).

(a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
(b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
(c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
(d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
(e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

All Project intellectual property, including the codebase, brand, and related inventions, has been irrevocably assigned to Credible Finance S.P.(Foundation), a segregated portfolio of Futarchy Governance SPC (Cayman Islands). The CRED token is enshrined as the ownership and oversight instrument of that segregated portfolio, so tokenholders collectively govern the entity that owns the IP through DAO. The operating business is conducted by Kiwimoney Inc., licensed MSB with FinCEN.

(b) Contract/admin powers

Governance operates through MetaDAO's futarchy decision-market framework: proposals are adopted or rejected based on conditional market outcomes rather than direct token voting. For the first three months post-fundraise, community proposals that materially impact the project (e.g., buybacks, liquidation, reduction of spending limits) are restricted per the fundraise terms, with MetaDAO retaining discretion to shorten this. Certain protective actions (enforcement remedies, conversion rights under the structure's credit arrangements) require SegCoDAO Approval, and an Emergency Supervisor is authorized to act upon defined adverse events.

(c) Locked-token rights (conditional)

No locking or staking mechanism granting additional rights exists. Lockups applicable to prior investors and team allocations are transfer restrictions only and confer no incremental governance or economic rights.

(d) Current tokenholder governance rights and economic arrangements

CRED represents community ownership of Credible and governs Credible Finance S.P.(Foundation) through MetaDAO decision markets. Tokenholders' presently operative rights include oversight of treasury actions and spending (the operating company draws a capped allowance of USD 250,000 per month from raise proceeds; treasury actions such as buybacks or changes to spending limits are subject to governance following the three-month restriction period), and approval rights over structural actions including termination of the segregated portfolio (which requires a CRED-holder vote with 90 days' advance public notice, with residual assets applied as tokenholders determine). No fee-routing, rewards, or buyback programs are presently operative.

(e) Control surface reliance

CRED is mintable; we plan to top up the team performance package via future governance proposals, similar to an option pool. Governance mechanics may evolve with the MetaDAO platform. No other changes to the governance/control model are currently anticipated.

(f) Dissolution authority

The segregated portfolio cannot be wound down unilaterally by the founders or operator. Termination requires SegCoDAO (CRED-holder) approval with at least 90 days' advance public notice, with residual assets applied as CRED holders determine. Upon defined adverse events, the Emergency Supervisor holds specified authority under the SPC's Articles.

Primary Foundation

Do the following for the Primary Foundation, defined below. If the primary foundation does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which were directly/indirectly involved in the issuance of the native token at launch. If the original foundation/DevCo has been dissolved and in its place a "new foundation/DevCo" was created, then detail the "new foundation/DevCo".

(a) Entity — Type and jurisdiction.
(b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. retained revenue), token administration, or reward parameters, and the method/threshold for each.
(d) Powers over DevCo — Explain whether the Foundation can exert direct or indirect influence over decision-making of the Developer Company.
(e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
(f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

The foundation-equivalent role is performed by Credible Finance S.P., a segregated portfolio of Futarchy Governance SPC, an exempted segregated portfolio company incorporated in the Cayman Islands. A segregated portfolio is not a separate legal person; the SPC acts for and on account of the segregated portfolio.

(b) IP ownership & control

Credible Finance S.P. owns all Project IP (codebase, trademarks/brand) pursuant to an irrevocable assignment from the founder(s). It has no subsidiaries. Futarchy Governance SPC, acting for the segregated portfolio, additionally holds a first-priority security interest over 100% of the equity of Kiwimoney Inc. together with a conversion right into 100% of that equity.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

The segregated portfolio does not exercise power over the DAO; the relationship runs the other way, the CRED holders govern the segregated portfolio through MetaDAO decision markets. Day-to-day execution is carried out by the appointed Operator subject to that governance.

(d) Powers over DevCo

Yes. The structure holds (i) a pledge over 100% of Kiwimoney Inc.'s issued equity with strict negative covenants (no transfers, no new issuances, no distributions), (ii) a conversion right into 100% of Kiwimoney Inc.'s equity, and (iii) automatic equity forfeiture and token clawback remedies against the founders for defined intentional misconduct.

(e) Contract/admin powers

Enforcement and conversion actions are subject to SegCoDAO Approval; an Emergency Supervisor may confirm and effect forfeiture/clawback upon defined adverse events.

(f) Current economic arrangements and distribution policies

Fundraise proceeds are held within the structure; the operating company draws a capped monthly allowance of USD 250,000 for operations. No mechanism currently exists directing protocol resources, fees, or token distributions to equityholders or contributors of this entity; the SPC's Articles prohibit distributions of profit to shareholders or directors.

Primary Developer Company

Do the following for the Primary Developer Company, defined below. If the primary Developer Company does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which were directly/indirectly involved in the issuance of the native token at launch. If the original foundation/DevCo has been dissolved and in its place a "new foundation/DevCo" was created, then detail the "new foundation/DevCo".

(a) Entity — Type and jurisdiction.
(b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. retained revenue), token administration, or reward parameters, and the method/threshold for each.
(d) Powers over Foundation — Explain whether the Developer Company can exert direct or indirect influence over decision-making of the Foundation.
(e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
(f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Kiwimoney Inc., a corporation incorporated in the state of Delaware, United States, operating the Credible Finance (registered as a Money Services Business with FinCEN).

(b) IP ownership & control

Project IP has been assigned to Credible Finance S.P. (see Section 4). Kiwimoney Inc. operates the Credible Finance payment orchestration product.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

None. Kiwimoney Inc. has no authority over DAO governance, the treasury, or token administration.

(d) Powers over Foundation

The founder (Shrikant Bhalerao) serves as the appointed Operator of Credible Finance S.P., providing services on an at-will basis subject to CRED-holder governance and the Emergency Supervisor framework. Kiwimoney Inc. itself holds no governance rights over the segregated portfolio.

(e) Contract/admin powers

No contract/admin powers.

(f) Current economic arrangements and distribution policies

Kiwimoney Inc. funds operations from (i) its business revenue (approximately USD 3.5M annual run rate) and (ii) the capped USD 250,000 monthly allowance from fundraise proceeds. The founders' token allocations are subject to price-based performance unlocks (minimum 18 months, tranches at 2x–32x of ICO price) and to clawback for defined misconduct. No dividends, buybacks, or distributions to holders exist or are permitted under the current structure.

Affiliated Protocol Contributor

Definition (for this section): An Affiliated Protocol Contributor (APC) is a non-issuer company - not the protocol's primary Foundation or DevCo - that materially contributes to the protocol's code, operations, governance, or funding. For example, Blockworks Advisory would be considered an APC of Ethena because it materially contributes to its operations through Ethena's risk council. Provide a structured description per APC. If no APCs exist, state that explicitly. Items below apply per APC; if an item isn't applicable to a given APC, leave it absent and note why briefly.

(a) Identity & role — Legal name, entity type, jurisdiction, and role (e.g., core development, security, infrastructure, market making, operations).
(b) Parameter control & scope — If any, what major protocol parameters the APC controls; include the method of authority (e.g., veto, majority, super-majority, "3/5 multisig"). If none, say so.
(c) Contract/admin powers — If any, provide the pause/upgrade powers (e.g., multisig pause), governance-executor authorities and limitations; include the method/threshold for each. If none, say so.
(d) Compensation and material economic arrangements — If any, protocol-generated resources or economic value is dynamically routed to the APC, describe the arrangement. Include the resource sources, routing mechanism, payment frequency, and duration. If no protocol resources or resources-linked economics are routed to the APC, state that explicitly.

(a) Identity & role

No Affiliated Protocol Contributors exist yet.

(b) Parameter control & scope

Not Applicable

(c) Contract/admin powers

Not Applicable

(d) Compensation and material economic arrangements

Not Applicable

Token Supply & Allocation

Initial Allocation

Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.

Ticker	Date	Allocation Category Name	Recipient Type	Allocation %	Allocation Tokens	TGE Unlock %	TGE Unlock Tokens	Cliff Months	Cliff Unlock %	Linear Vesting Months	Cadence Months	Circulating Treatment	Notes on what each category is used for	If applicable: Contract / Wallet address
CRED	17-07-2026	ICO	Public / Sale	0.44124031	10000000	1	10000000	0	0	0	1	Yes	holding	holding
CRED	17-07-2026	Liquidity Provisioning	Liquidity	0.12795969	2900000	1	2900000	0	0	0	1	Yes	holding	holding
CRED	17-07-2026	Prior Investors	Private / VC	0.2308	5230709	0	0	12	0.3333	24	1	No	Prior Investors	DVA4Q78r3N35gHFeKyMWEMP9jtv4f5joteDz3kMZTYjL
CRED	17-07-2026	Performance Package	Insiders	0.2	4532678	0	0	18	1	0	1	No	Founding Team	5WPaWCwyWEt74dFMNMqeah2AZRpLPP1KTrQwm2eAanqr

Vesting Insider Tokens

If there are not post-TGE token compensation plans, state explicitly they do not exist. If there are, state each of (A)–(B) below.

(a) Post-TGE employee lock as % of total supply — State the current total amount of tokens locked or unvested attributable to post-TGE employees, expressed as a percentage of total supply.
(b) Typical post-TGE vesting schedule — Describe the standard vesting terms used for post-TGE grants, including: cliff length (or "no cliff"), vesting frequency (e.g., monthly/quarterly), and total duration.

(a) Post-TGE employee lock as % of total supply

No post TGE compensation plan exists for the new employees.

(b) Typical post-TGE vesting schedule

Not Applicable

Disclosure of Token Advisory Billings

Disclose current token-based compensation for external advisors and service providers (e.g., legal, marketing, technical, growth) funded from the on-chain treasury. Do not disclose individual payments to advisors receiving fiat-only compensation.

(a) Existence — Whether any such token-based payments or advisory commitments exist (or explicitly state that no token-based compensation for advisory commitments exist).
(b) Total token allocation — The total token allocation across all advisory services.
(c) Payer entity — The payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury).
(d) Description of advisory/services — A brief description of the advisory/services (e.g., "legal and regulatory advisory," "growth and BD support," "security advisory").

(a) Existence

There is a 1.58% of the total Tokens i.e., 358,082 CRED tokens have been allocated for the advisors including the marketing, growth and legal advisory services. All these tokens are locked under the Prior Investors terms.

(b) Total token allocation

358082

(c) Payer entity

Credible Finance S.P.

(d) Description of advisory/services

The services provided by the advisors for growth, marketing and legal have been assigned tokens for their services in their relevant fields in due process of onboarding new clients and legal structuring.

KOL Marketing Activities

Disclose ongoing KOL/influencer relationships that partially or fully received tokens for payment. Do not need to disclose KOL/influencers that do not receive tokens for payment.

(a) Existence & scope — State plainly whether KOLs receive tokens for payment, if none say so.
(b) Usernames & roles — List usernames/handles (with platforms) for KOLs that received token-based compensation and describe the nature of their activities. Legal names are not required.
(c) Token allocation & vesting/locks — Provide the aggregate token amount across all such arrangements and summarize vesting, lock, or release terms.

(a) Existence & scope

None

(b) Usernames & roles

Not applicable

(c) Token allocation & vesting/locks

Not applicable

Labelled Unissued & Operational Token Wallets

For each wallet that holds Unissued Tokens or is essential to operations (e.g., foundation, operations, treasury, investor reserve), disclose:

(a) A category label explaining the wallet's primary function.
(b) chain the wallet is on.
(c) The unique address of the wallet.
(d) The mechanism of control (e.g., DAO, multisig).
(e) One verification link to a blockchain explorer. Definition: Unissued Supply = tokens authorized by the contract but not yet issued to any party; where they sit (treasury or mint authority) does not change that they are unissued. For instance: if a token has a total supply cap of 1B, and 400M tokens have been issued to investors, the team, and users (whether vested or unlocked), then those 400M count as issued supply. The remaining 600M are authorized but unissued supply, even if they are already minted into a DAO treasury wallet.

Title	Primary Function	Chain	Address	Control Mechanism	Explorer Link
Prior Investors	Allocation for the existing investors with token lockup	Solana	DVA4Q78r3N35gHFeKyMWEMP9jtv4f5joteDz3kMZTYjL	Multistig - DAO Controlled	https://solscan.io/account/DVA4Q78r3N35gHFeKyMWEMP9jtv4f5joteDz3kMZTYjL
Team Performance Package	To be unlocked on meeting the price based milestones with minimum of 18months lockup	Solana	5WPaWCwyWEt74dFMNMqeah2AZRpLPP1KTrQwm2eAanqr	Multistig - DAO Controlled	https://solscan.io/account/5WPaWCwyWEt74dFMNMqeah2AZRpLPP1KTrQwm2eAanqr
Foundation Treasury	The ICO raise proceeds after the liquidity allocation is locked here and is accessible by the Dev Co., through monthly allocation	Solana	ATESfxbwt3SRhSHc4nbk8BG6P8Nm8TAjsHfQCbgC2er4	Multistig - DAO Controlled	https://solscan.io/account/ATESfxbwt3SRhSHc4nbk8BG6P8Nm8TAjsHfQCbgC2er4

Transactions & Market Structures

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:

(a) Market maker's name — the market maker's name;
(b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
(c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
(d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.

Market Maker Name	Token Allocation Committed	Term Duration	Structure Name
No Market Maker agreements entered

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:

(a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
(b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
(c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
(d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Exchange Name	Token Allocation Committed	Term Duration	Native Token Listing Fees
Meteora Pool	899999.999868	None	0
Futarchy AMM Pool	2000000	None	0

Liquidity Deals and Market Activity

If a category does not exist or is not applicable, make that clear in plain language (no specific wording required).

(a) Token repurchases or secondary-market accumulations (if any) — Source of funds, treatment (burn, treasury retention, POL, redistribution, or other), controller/approvals, and whether those tokens may be re-used, re-issued, or permanently removed from circulation.
(b) Protocol-owned liquidity (POL) — Where deployed, total token or dollar size across deployments, controller, and unwind/exit policy.
(c) Liquidity deals / purchased TVL — The total size across all deals, and where the capital participates - no counterparty names needed.
(d) Token-secured loans/lines (incl. against unissued tokens) — Principal, gross position size, collateral, counterparties, and unwind/exit policy.

(a) Token repurchases or secondary-market accumulations (if any)

Not applicable

(b) Protocol-owned liquidity (POL)

Protocol-owned liquidity has been deployed on Meteora and the Futarchy AMM pools as part of the standard program for MetaDAO launches, totaling 2.9M CRED tokens. The Futarchy AMM pool holds 2M CRED tokens paired with 800,000 USDC, and the Meteora pool holds 0.9M CRED tokens as single-sided liquidity. All protocol-owned liquidity is controlled by the DAO through a multisig wallet. Any withdrawal or redeployment of this liquidity requires DAO governance approval.

(c) Liquidity deals / purchased TVL

Not Applicable

(d) Token-secured loans/lines (incl. against unissued tokens)

Not Applicable

Resource Disclosures

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:

(a) Series Name / Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
(b) Date of sale (at least month & year).
(c) Number of tokens sold (or % of total supply)
(d) Vesting schedule If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.")

Series Name	Investment Vehicle	Date Of Sale	Number of tokens sold	Vesting Schedule
Prior Investors and Advisors	STAMP	July 2024	5230709	Vesting Schedule: 12-month cliff, 33% unlock at cliff date, remaining 67% vested monthly over 24 months thereafter

Operational Funding, Economic Flows, and Resource Provisioning

Provide a narrative description of the Project's material funding sources, economic flows, and operational provisioning, broken out by entity: Foundation, Lab/DevCo, and DAO. If an entity does not exist, state that explicitly. If an entity exists but does not pursue revenue-generating activity, state how it funds or provisions its operations.

(a) Entity existence — Explicitly state whether each of Foundation, Lab/DevCo, and DAO exists.
(b) Material sources of funding or economic inflows — For each existing entity, describe its primary sources of operational funding or economic inflows, if any (e.g., service fees, grants, donations, treasury reserves, token reserves, staking rewards, validator/sequencer income, partnership payments, retained revenue, or other protocol-related receipts). If none, state "none."
(c) Operational use of resources — Briefly describe how those resources are generally used (e.g., development, operations, security, ecosystem support, grants, liquidity support).
(d) Onchain Resource Usage — Provide links to public dashboards and token holder relations reports that help explain on-chain financial activity, treasury activity, fee flows, rewards, or other protocol-controlled resources. Make certain to explain what each link is for.

(a) Entity existence

Foundation (Credible Finance S.P.) exists. Developer Company (Kiwimoney Inc.) exists. DAO exists (governed through MetaDAO).

(b) Material sources of funding or economic inflows

Material sources of funding or economic inflows:

Foundation (Credible Finance S.P.): Primary sources are (i) ICO fundraise proceeds (approximately $4M raised, held in reserve and liquidity pool),

Developer Company (Kiwimoney Inc.): Primary sources are (i) retained business revenue of approximately $250,000 monthly from payments services, and (ii) monthly DAO allocation of $250,000 from the Foundation.

DAO: The DAO does not generate direct inflows. It holds discretion over unallocated fundraise reserves and governs the allocation of resources to the Foundation and DevCo.

(c) Operational use of resources

The combined $500,000 monthly allocation (business revenue plus DAO allocation) is deployed toward (i) core development and engineering, (ii) operations and infrastructure costs, (iii) security audits and compliance, (iv) team compensation, (v) licensing, fee and commission for payment gateways, banks, payment service providers and (vi) ecosystem support and partnerships. ICO fundraise reserves are held for long-term operational sustainability and strategic initiatives as approved by DAO governance.

(d) Onchain Resource Usage

The treasury activity can be accessed on: https://solscan.io/account/ATESfxbwt3SRhSHc4nbk8BG6P8Nm8TAjsHfQCbgC2er4.

Onchain Proposals and their activity can be accessed on https://www.metadao.fi/projects/credible

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

(a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
(b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
(c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
(d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
(e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
(f) References (optional) — Link(s) to post-mortem/advisory/PR.

(a) Date & component affected

No exploits affecting tokenholders or protocol funds as of 2026-07-22

(b) Exploit vector summary

Not Applicable

(c) Quantified impact

Not Applicable

(d) Remediation/response taken

Not Applicable

(e) Current status

Not Applicable

(f) References (optional)

Not Applicable

[Optional] Offchain Foundation Or DevCo Income Statement

Provide a single income statement, expense summary, or comparable operating statement for the primary Foundation or Developer Company. A consolidated or entity-level presentation is acceptable. Balance Sheet and Statement of Cash Flows may be included but are not required. This item is intended to provide transparency into offchain operating resources and expenditures only.

This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Credible Finance is solely responsible for the content, accuracy, and legality of its disclosures.