Sports Sponsorship, Fundraising & NFT Fintech Platform Case Study

Athletes and teams can create public or private campaigns with a goal, category, location and a transparent allocation plan. Training, equipment and player-pool allocations must total 100% before launch. Campaigns can accept card payments, cryptocurrency or both, while administrators can review transactions and prepare payout batches.

Sponsors fund a wallet once and use its available balance to make offers. When a sponsorship is approved, the committed amount moves to an on-hold balance. A milestone release captures the relevant amount, a failed milestone returns it to available funds, and the beneficiary balance becomes eligible for withdrawal. This architecture supports longer commitments without relying on expiring card authorizations.

Offers move through a defined state model – Pending, Submitted and Approved – with explicit Dispute, Failed and Cancelled branches. An activity log records transitions, and administrators hold final authority for disputes and payouts.

• Tokenized card gateway: Saved customer profiles are used so raw card data does not reach the platform application.
• Signed redirect gateway: JWT-signed requests reduce tampering risk, while the gateway webhook remains the transaction source of truth.
• Direct crypto contributions: The platform checks the submitted transaction against blockchain RPC nodes before recording the donation.
• Payout operations: Approved withdrawals are organized into the bank’s required batch format with configured reference masters.

The platform scans a connected wallet through Rarible, with OpenSea v2 as a fallback, across six supported EVM networks and test environments. Users can bulk-import discovered assets or add a contract address and token ID manually. The inventory captures contract, token ID, collection, image, chain, token standard, royalty and creator-wallet details.

At import, direct JSON-RPC reads check ERC-721 ownership with ownerOf or ERC-1155 balances with balanceOf. A composite duplicate rule prevents an active asset from being imported twice by the same user. RPC failures are logged and currently follow an availability-first, fail-open policy; that boundary should remain visible in technical documentation.

The marketplace provides public browsing, search, filters, sorting and listing details. Sellers select an inventory NFT, a supported listing currency and administrator-managed category and rarity values. Creator identity and wallet details are retained from the first listing so eligible secondary-sale royalties can be calculated consistently.

For on-chain listings, the Solidity contract exposes list, buy and delist functions. A buy settles the seller amount, secondary-sale royalty and platform fee atomically. The default platform fee is 2.5% and administrators can adjust it up to a 10% hard limit; royalties are constrained to 0-10%. Non-reentrant purchase logic, emergency pause capability and server-side row locking reduce contract and concurrency risk.

The platform retains a legacy direct-transfer path for older listings. Its server record uses a submitted transaction hash without independently validating mining and transfer validity at purchase time. This known gap should be closed before the next high-volume marketplace release and must not be described as fully verified.

Campaigns can use two distinct reward models. A reward tier represents a future instant- or lazy-mint promise with price, quantity, royalty, blockchain and notes. An attached inventory reward represents a specific NFT already owned by the campaign creator; authorization is checked and a campaign can attach up to 50 inventory items. A campaign may use either model, both or neither.

Administrators manage user approvals, identity-document review, sensitive profile changes, master data, role permissions, content moderation, disputes, payout batches and transaction oversight. Text moderation first checks a configurable dictionary and then uses Azure OpenAI. If the AI service is unavailable, messaging continues with reduced moderation quality – an intentional fail-open choice that should be monitored operationally.

DreamzTech used written product requirements, API contracts, weekly status reporting and a four-gate delivery model: Investigate, Plan, Execute and Verify. An independent code review identified critical, high and medium findings. Remediation included reentrancy protection, emergency pause capability, row locking, direct ownership reads, royalty limits, route ownership checks, fail-closed permissions, recursive log masking, key rotation, token invalidation and dependency triage.