How API Works
A modular API for DApps to integrate with FirstBatch (version 0.1)
DApps can integrate with FirstBatch using its flexible API and build custom interactions based on their needs. FirstBatch delivers maximum efficiency and flexibility for DApps while preserving the privacy of users.
By design, FirstBatch is an off-chain & on-chain hybrid structure. In order to be available for both fully decentralized and semi-decentralized applications, FirstBatch offers a DApp dashboard that can be used by a single operator removing the need to create external backends and webhooks.
FirstBatch API is built around the idea of better UX within web3.0. Relayers on the Polygon network offer zero gas smart contract interactions for users.
Meanwhile, easy integration for both fully and semi-decentralized applications is the essence of the modular, hybrid architecture of FirstBatch. DApps can use FirstBatch without a dedicated backend while remaining private for users.
In order to use FirstBatch with full capability, DApps have to:
- 1.Register their DApp
- 2.Provide MATIC
Rest is completely handled by FirstBatch. All operations can be managed through the dashboard with a single operator.
FirstBatch deploys smart contracts on behalf of DApps, for permission management, asset delivery and gasless proofs.
API is made of blocks that can be attached and sequenced to create custom models. They are abstractions for user<->dapp interactions.
Events are at the heart of FirstBatch API. Everything is an event. Each desired functionality is an event. Events can be created anytime and can be set to start and end at a certain time & date.
Each event has its own set of participants. DApps can generate links that allow Persona NFT owners to participate in them, using semaphore identities. Events are eligible for participation for anyone with PNFTs by default.
Event objects offer aggregated statistics of interests, persona traits, and personhood ranks based on participants. A DApp can generate an event and a link instantly and ask its user base to participate and obtain aggregated statistics. This requires no proof and doesn't reveal any personal information.
Gates are attached to events, to provide permission management. Gates can prevent certain users from participating based on interests, traits, and PoP.
Gates are attached to events to disallow PNFT owners to participate if not they are not members of the desired group.
They can only be passed by verifying snark proofs on-chain, by the user.
Permissions are stored on-chain allowing DApps to query their own FirstBatch-DApp contract with a wallet id, and an event id to see if a wallet is allowed to participate in a certain event. These lookups can't be used by FirstBatch since wallet ids are not stored off-chain.
This permission management system on-chain is essential for Metaverses in particular to allow gated interactions of any kind. On the other hand, this makes client-side app completely eligible for using FirstBatch.
If a DApp needs multiple interests or a complicated logic to gate participation in an event, it can create custom personas and generate new groups. This reduces the number of required proofs to one per user even for multiple interests.
Custom Persona using boolean logic
Incentives are blocks for distributing rewards to participants of a certain event. They are on-chain assets, managed by FirstBatch-DApp specific contracts.
Filters work like gates, but they are post-gates. If an event is followed by another event or an incentive, DApps can add filters based on the participant's aggregated data to disallow participating in the upcoming event.
Filters are specifically crucial for segmented airdrops.
Any DApp can use FirstBatch on any chain for two reasons;
1- Users don't pay for gas
2-DApps own contract is not required to interact with FirstBatch contracts
Given these arguments, FirstBatch can be deployed to many blockchains simply by migrating contracts.