Delivery window: 20 weeks from T0. T0 marks program acceptance and project kickoff; all subsequent milestones are measured from that date.
1. Integration thesis and priorities
BWB proposes to extend to Stellar the regulated-investment capabilities already implemented on Base: offering administration, investor and distributor workflows, wallet orchestration, KYC/KYB, eligibility controls, investment processing, and asset and income distribution. The proposed scope is limited to new Stellar/Soroban engineering and the integration layer required to connect these capabilities. Existing EVM code, legal expenses, external audits, marketing, and user acquisition are excluded from the US$150,000 project budget.
Delivery priorities are sequenced as follows:
Distribution & Commissioning: private access, individualization, attribution, and commission by offering, office, and member.
Yield and lending: segregated, partner-operated access, with no management, custody, credit origination, or return guarantees by BWB.
Remaining scope items: Notus KYC/KYB, the Transfero BRL ramp, Etherfuse as a conditional Stellar-native fallback, D4Sign, liquidity for non-security assets, and the DIGITAS/B3 adapter.
Every deliverable is designed around Brazil’s LGPD and CVM Resolution 88: PII and documents remain off-chain; ownership records are individualized; consents and risk disclosures are versioned; payment flows remain segregated; and CVM 88 offering tokens are excluded from BWB-operated AMM or multilateral matching routes.
2. Reusable existing implementation
Domain
Reusable work
Future development
React/SSR, TypeScript, and Convex
User journeys, interfaces, authentication, and data
Stellar states and components
IInvestmentManager and Notus
Preparation, signing, execution, and reconciliation
StellarInvestmentManager and Soroban authorization
Access/allowlist
Authorization, revocation, and per-offering caps
Soroban enforcement by offering and investor
Distributors
Invitations, relationships, attribution, metrics, and dashboards
Attribution ledger and commission engine
KYC/KYB
States, webhooks, polling, encryption, and frontend
Notus adapters and controlled Avenia migration
Ramp provider
Generic contract and modeled states
TransferoRampProvider, EtherfuseStellarProvider, callbacks, and reconciliation
EVM contracts
Sales, cooling-off, refunds, snapshots, claims, and income
Selective Soroban reimplementation
Subgraph
Events and analytics models
Stellar indexer
The principal new distribution component is the commission engine: versioned rules, deterministic source attribution, closing periods, dual approval, reversals, and reconciliation. This work is explicitly included in Tranche 1.
2.1. Repository implementation plan
Priority
Current baseline
Planned Stellar work
P0 — Delivery roadmap
The repository contains an earlier 14-week planning document.
Publish the 20-week, US$150,000 roadmap with T0 (10%), T1 (20%), T2 (30%), and T3 (40%), aligned to the priorities and acceptance criteria in this document.
P0 — Commercial distribution
No modules exist for attribution, affiliates, or commission by offering, office, and member.
Document the future offering-access, distribution-attribution, and commission-ledger domains, including their events, versioned rules, idempotency, approval, and reversal. Most can stay in the private backend; the public repository should expose verifiable interfaces and schemas.
P0 — Eligibility
The whitelist is shared and records investor category; there is no authorization or individual cap per offering.
Extend the specification to pseudonymous eligibility by offering and investor, maximum/consumed allocation, expiration, revocation, and no on-chain PII. Define migration and compatibility with the current contract.
P0 — Regulated offering
The token implements issuance and controlled transfers, but does not model subscription, cooling-off, cancellation/refund, or payment reconciliation.
Add an offering/subscription contract or module to the specification with states, caps, pause, withdrawal, offering failure, and reconcilable events, using the existing EVM implementation as a functional reference.
P1 — SDK
token.ts, kyc.ts, and anchor.ts contain unimplemented methods; the package name differs between manifest and documentation.
Plan clients by interface: account, eligibility, offering, commission, indexer, Notus identity, Transfero ramp, Etherfuse Stellar services, D4Sign, DeFindex/Blend, and B3 adapter. Standardize the package name, XDR generation, simulation, signing, polling, errors, and tests.
P1 — Notus
The architecture assigns the Stellar wallet to Privy and contains no Notus KYC/KYB adapters.
Reposition Notus as the primary account-abstraction/identity integration and define KYC/KYB interfaces, callbacks, and states. Use Etherfuse Embedded Wallets as a Stellar-native fallback subject to key-control, KYC coverage, LGPD, and data-processing review.
P1 — Transfero and Etherfuse
anchor.ts is a SEP-24/SEP-31 scaffold, while the effective BRL-to-Stellar route remains partner-dependent.
Specify TransferoRampProvider for Pix/BRL and EtherfuseStellarProvider for sandbox validation of Stellar wallets, ramps, swaps, trustlines, claimable balances, signed webhooks, and XDR regeneration. Etherfuse becomes a BRL fallback only after production availability for Brazil is confirmed; retain AlfredPay, BlindPay, and Abroad as additional candidates.
P1 — Income distribution
distribution still throws an error and assumes iteration over all holders, while the token maintains no usable enumeration.
Define a scalable and verifiable model before implementation: off-chain indexing with an authorized batch, Merkle/claim, or snapshot. Separate offering dividends from DeFi yield/lending and include DeFindex/Blend adapters without discretionary management by BWB.
P2 — D4Sign and B3
No modules, interfaces, or documents exist for signatures and DIGITAS/B3.
Add specifications for D4SignSignatureProvider and DigitasB3Adapter, including HMAC webhooks, off-chain evidence, optional hashes, schemas, idempotency, DvP, reconciliation, formal mocks/sandboxes, and cost/production limits.
P2 — Liquidity
The repository does not clearly distinguish settlement assets from CVM 88 securities.
Document Soroswap/Aquarius and Etherfuse swap routes only for non-security settlement assets, with policy tests that reject offering tokens from every swap route.
P2 — Evidence and operations
Implementation status and verification evidence require clearer separation.
Mark each item as implemented, scaffold, planned, or partner-dependent; publish a requirement–file–test matrix, CI results, contract IDs by network, environment variables, runbooks, and evidence. Mocks and partner assumptions will be labeled explicitly.
This table distinguishes the reusable baseline from the work proposed for the 20-week delivery window. Repository issues and milestones will map each of the eight deliverables to source files, tests, deployment evidence, and partner dependencies.
3. Notus: account abstraction and KYC/KYB
Notus is the preferred account-abstraction and identity integration partner. The proposed architecture preserves BWB’s provider boundaries so that identity state, wallet orchestration, and Stellar transaction authorization remain independently testable.
Notus’s current public documentation describes EVM smart wallets and does not list Stellar as a supported network. BWB therefore treats native Stellar support as a partner dependency rather than an existing capability:
BWB will preserve provider interfaces;
EIP-4337/EIP-7702, Kernel, bundler, and UserOperation concepts will be replaced by a native Stellar adapter;
Notus KYC/KYB will be integrated behind the existing state machines;
scope, sandbox access, endpoints, SLA, and Stellar support require written confirmation before implementation;
Etherfuse Embedded Wallets is the preferred Stellar-native fallback; Stellar Wallets Kit, Privy, or DFNS remain alternatives if key-control or coverage requirements are not met.
Transfero will be the primary on-ramp/off-ramp partner. Its infrastructure documents APIs for BRL accounts, Pix-in, Pix-out, payments, KYC/AML, and conversion between fiat and digital assets, including BRL, BRZ, and USDC use cases.
Proposed scope:
TransferoRampProvider behind the existing ramp contract.
User onboarding/enablement under responsibilities defined with Transfero.
Pix-in/Pix-out generation and tracking.
Conversion and settlement without investor funds passing through a BWB account.
Idempotent callbacks, reconciliation, and a complete trail through investment or withdrawal.
Commercial confirmation of assets, networks, and the effective route to USDC/a Stellar settlement asset.
Public documentation confirms Transfero’s BRL/crypto infrastructure but does not explicitly confirm native Stellar settlement. Native settlement is therefore a readiness gate for this integration. If the route is unavailable, Etherfuse, AlfredPay, BlindPay, or Abroad will be selected as the named fallback after review of BRL/Pix availability, Brazilian coverage, contracting, compliance, and settlement. Etherfuse is eligible for the BRL role only after production support for Brazil is confirmed.
Etherfuse will be evaluated behind the same provider interfaces as a Stellar-native fallback for embedded wallets, KYC/KYB, on/off-ramps, Stablebond access, and non-security asset swaps. Its documentation confirms native Stellar support for ramps and swaps, automatic account and trustline setup during first-time on-ramps, claimable-balance delivery, signed asynchronous events, transaction regeneration, and optional SEP-24 off-ramps.
The initial implementation is a sandbox proof of compatibility within the existing account, identity, ramp, and settlement abstractions. It will verify:
non-custodial embedded-wallet provisioning and explicit user authorization;
automatic Stellar account, XLM reserve, and trustline setup on the first on-ramp;
idempotent KYC/KYB and order-state reconciliation through authenticated webhooks;
Stablebond-to-USDC and other approved non-security settlement swaps;
handling and regeneration of short-lived Stellar XDR transactions.
Etherfuse currently documents Brazil/BRL as upcoming. It therefore does not replace Transfero in the delivery baseline and will not be presented as an active Pix/BRL provider until production availability, pricing, limits, liquidity, KYC coverage, LGPD terms, data location, SLA, and regulatory responsibilities are confirmed in writing. Etherfuse does not replace Soroban eligibility contracts, the commission engine, D4Sign, DeFindex/Blend lending, or the DIGITAS/B3 adapter.
D4Sign will be the document-signing partner through its REST API, sandbox, optional embed, HMAC webhooks, electronic signature, and ICP-Brasil e-CPF/e-CNPJ in PAdES/CAdES. Documents, PII, certificates, and evidence remain off-chain; Stellar optionally receives only the hash and final state. The solution will not be described as a GOV.BR signature.
DIGITAS/B3
B3 Digitas does not publish a dedicated price schedule for its crowdfunding solution. The platform may include tokenization, custody, settlement, PIX, ownership records, and trading, subject to contracting, credentials, certification, and enablement. The US$25,000 Tranche 3 allocation covers the BWB/Stellar adapter, contract tests, and reconciliation layer. B3/Digitas licensing, onboarding, custody, settlement, support, and transaction fees are third-party operating costs excluded from the US$150,000 project budget.
6. Partners
Need
Primary
Fallback/condition
AA and UX
Notus + Stellar adapter
Etherfuse Embedded Wallets; Stellar Wallets Kit, Privy, or DFNS
KYC/KYB
Notus
Etherfuse subject to Brazil/LGPD review; Avenia during migration
BRL ramp
Transfero
Etherfuse after Brazil launch; AlfredPay, BlindPay, or Abroad
Yield
DeFindex
Etherfuse Stablebonds as a separately assessed product; segregated from CVM 88 offerings
Lending
Blend v2
Operated by the applicable partner, not BWB
Signing
D4Sign
Electronic/ICP-Brasil, not native GOV.BR
Settlement liquidity
Soroswap/Aquarius
Etherfuse swaps; non-security assets only
Regulated rail
DIGITAS/B3
Access, pricing, and certification subject to contract
7. Delivery schedule and tranche costs
Stage
Acceptance point
Share
Tranche cost
T0 — Project kickoff
Program acceptance and kickoff
10%
US$15,000
T1 — MVP
Acceptance by the end of week 8
20%
US$30,000
T2 — Testnet
Acceptance by the end of week 14
30%
US$45,000
T3 — Mainnet
Acceptance by the end of week 20
40%
US$60,000
Total
20 weeks
100%
US$150,000
The total project cost is US$150,000 across four acceptance points. Deliverables 1–8 account for US$135,000 in T1–T3; the US$15,000 T0 tranche covers the engineering setup required to begin the MVP.
T0 cost breakdown: integration engineering mobilization and provider-interface refinement (US$6,000); Stellar environments, CI, and test fixtures (US$5,000); partner sandboxes, technical credentials, and the initial evidence baseline (US$4,000). T0 applies only to new project work and excludes prior development, audits, legal services, and marketing.
T1 delivers the regulated-account, private-offering, attribution, and commission MVP. T2 covers testnet integrations for DeFi, identity, the BRL ramp, and document attestations. T3 covers mainnet deployment, production observability, the DIGITAS/B3 adapter, and the open-source evidence package.
Cost structure: T0 is US$15,000 (10%), T1 is US$30,000 (20%), T2 is US$45,000 (30%), and T3 is US$60,000 (40%). Each tranche is tied to the schedule and measurable acceptance criteria below.
Tranche 1 — MVP: Distribution First
Deliverable 1: Regulated Stellar Account and Private Offering Foundation
Description: Implement a native Stellar account adapter, Soroban eligibility and investor-allocation contracts, and Stellar event reconciliation into the existing BWB domain while preserving the Notus-led account and identity experience.
How to Measure Completion:
seedless Stellar account creation or linking works in the BWB flow;
a Soroban offering restricts participation and enforces per-investor allocation;
at least 20 automated authorization, allocation, pause and idempotency tests pass;
no PII or KYC document is stored on-chain;
Notus collaboration scope is confirmed or the approved Etherfuse/alternative wallet fallback is active.
Estimated Completion Date: Week 6 after T0.
Deliverable Cost: US$12,000 Part of the US$30,000 T1 tranche. T0 covers the shared engineering setup; any proprietary work required by Notus is excluded from this project budget.
Deliverable 2: Distribution Attribution and Commissioning MVP
Description: Extend the existing distributor relationships, private-offering access and dashboards into a deterministic commission engine by offering, office and member, including referral attribution, approvals, reversals and reconciliation.
How to Measure Completion:
versioned commission rules operate by offering, office and member;
referral links attribute qualified investments without exposing PII;
each confirmed investment creates one idempotent commission-ledger entry;
dashboards show sold units/value and pending, earned and reversed commissions;
3 offices, 10 members, 50 investors and 100 simulated investments complete without duplicate commission.
Estimated Completion Date: Week 8 after T0.
Deliverable Cost: US$18,000 Together with Deliverable 1, this equals the US$30,000 T1 tranche. Third-party tax, accounting, and commission-payment services are excluded.
Tranche 2 — Testnet Integrations
Deliverable 3: Partner-Operated Yield and Lending Experience
Description: Integrate DeFindex and Blend v2, directly or through the eligible operating partner, in a product area segregated from CVM 88 offerings. BWB will not select investments, guarantee returns, originate credit, or custody assets.
How to Measure Completion:
at least one DeFindex testnet deposit and withdrawal completes;
a Blend supply/borrow or partner-operated lending flow is demonstrated;
every action requires explicit user authorization and risk disclosure;
CVM 88 returns and DeFi yield are displayed separately;
failure, retry, reconciliation and paused-pool tests pass.
Estimated Completion Date: Week 12 after T0.
Deliverable Cost: US$20,000 Covers the testnet integration. Licenses, initial liquidity, custody, and regulated-partner operating requirements are excluded.
Deliverable 4: Identity and BRL Ramp Testnet
Description: Add Notus KYC/KYB adapters behind the existing provider interfaces and integrate Transfero as the primary BRL on/off-ramp. Validate Etherfuse in sandbox as a conditional Stellar-native fallback for embedded wallets, identity states, ramps, Stablebonds, and swaps. The selected production provider will handle the applicable regulated payment, liquidity, and compliance operations; BWB will orchestrate eligibility, user authorization, and reconciliation without receiving investor funds.
How to Measure Completion:
Notus KYC and KYB handle approved, rejected, expired and review states;
signed callbacks are idempotent and evidence is exportable;
existing Avenia records remain traceable during migration;
one Transfero Pix/BRL deposit and one withdrawal reach reconciled terminal states in sandbox;
the BRL-to-digital-asset route and the final Stellar settlement step are documented and tested;
an Etherfuse sandbox flow validates a Stellar wallet, trustline/claimable-balance setup, authenticated webhook reconciliation, and XDR regeneration;
if Transfero cannot support the required route, one documented fallback is activated following Stellar reviewer approval; Etherfuse may fill the BRL role only after its Brazil launch is confirmed.
Estimated Completion Date: Week 14 after T0.
Deliverable Cost: US$15,000 Covers provider adapters and sandbox compatibility flows, including Etherfuse validation within the same interfaces. Provider onboarding, identity checks, transaction volume, liquidity, FX spreads, and custom settlement services are excluded.
Deliverable 5: D4Sign Signature and Stellar Document Attestation
Description: Integrate D4Sign into offering documents, terms and risk acknowledgements, and implement a privacy-preserving Stellar attestation layer. After D4Sign confirms completion through an authenticated webhook, BWB will create a canonical evidence hash and register an offering-specific attestation linked to the investor's Stellar account. Soroban eligibility controls will require a valid attestation for the current document version before subscription or token issuance. PDFs, certificates, evidence packages and personal data will remain off-chain.
How to Measure Completion:
D4Sign upload, signer configuration, signature and completion work in sandbox;
authenticated HMAC webhooks produce idempotent evidence records;
each completed signature produces a verifiable canonical hash and a Stellar attestation;
the attestation identifies the offering, document version and investor Stellar account without exposing PII;
subscription or token issuance is rejected when the attestation is absent, revoked or superseded;
a verification page confirms whether a supplied document matches its on-chain hash;
final PDFs, certificates and D4Sign evidence packages remain retrievable off-chain;
10 pilot users complete the signature-to-attestation journey and at least 80% do so without assisted recovery.
Estimated Completion Date: Week 14 after T0.
Deliverable Cost: US$10,000 Covers the D4Sign API integration, Stellar attestation module, and verification flow. Subscription fees, ICP-Brasil usage, authentication credits, and recurring document volume are excluded.
Tranche 3 — Mainnet
Deliverable 6: Mainnet Distribution and Commissioning Launch
Description: Deploy the regulated offering, eligibility, attribution and commission components to mainnet and connect the production investor, distributor, issuer, identity and settlement journeys.
How to Measure Completion:
public contract IDs and repositories are verifiable;
one offering and at least two distribution offices are configured;
at least 25 eligible real users complete onboarding;
at least one real investment reaches settlement, attribution, and commission reconciliation;
monitoring, pause controls, alerts and an incident runbook are live.
Estimated Completion Date: Week 17 after T0.
Deliverable Cost: US$25,000 Covers the production release, operational controls, and observability. External audits, scaled infrastructure, and regulated operations are excluded.
Deliverable 7: Permitted Liquidity and DIGITAS/B3 Adapter
Description: Deliver a separated non-security settlement swap path and a regulated DIGITAS/B3 adapter for schemas, status, idempotency, reconciliation and exceptions. BWB security tokens will never enter the AMM route.
How to Measure Completion:
an approved XLM/USDC or equivalent settlement pair can be quoted and swapped;
routing rejects CVM 88 offering tokens;
the DIGITAS/B3 adapter passes contract tests against an authorized sandbox or formally agreed mock;
delivery-versus-payment and the prevailing ownership record are documented;
production connectivity is claimed only when actual B3/Digitas access is available.
Estimated Completion Date: Week 19 after T0.
Deliverable Cost: US$25,000 Reflects the integration and certification complexity of the BWB/Stellar adapter. B3/Digitas contracting, licensing, onboarding, custody, settlement, and service fees are excluded.
Deliverable 8: Open-Source Release and Final Verification
Description: Publish reusable Soroban contracts and adapters, complete production verification and documentation, enable privacy-safe telemetry, and deliver the final Stellar evidence package.
How to Measure Completion:
reusable contracts and adapters are released under an OSI-approved license;
CI publishes unit and integration test results;
deployment, event and API documentation is reproducible;
dashboards report Stellar accounts, investments, volume and failures without PII;
the final demo maps every acceptance criterion to accessible evidence.
Estimated Completion Date: Week 20 after T0.
Deliverable Cost: US$10,000 Covers documentation, release, and internal verification. Independent audits and ongoing support are excluded.
Implementation readiness gates
Confirm the Notus collaboration scope for Stellar account orchestration and KYC/KYB, including sandbox access, technical ownership, and SLA.
Confirm Transfero support for Pix, BRL, target assets and networks, the Stellar settlement route, sandbox access, KYC/AML responsibilities, pricing, and SLA.
Complete an Etherfuse sandbox proof of compatibility covering embedded wallets, KYC/KYB states, Stellar ramps, trustlines, claimable balances, swaps, signed webhooks, and XDR regeneration.
Confirm Etherfuse’s Brazil/BRL production date, Pix support, limits, pricing, liquidity, KYC coverage, LGPD terms, data location, SLA, and regulatory responsibilities before designating it as a BRL fallback.
Complete due diligence and designate Etherfuse, AlfredPay, BlindPay, or Abroad as the documented BRL-ramp fallback.
Confirm the D4Sign API plan, HMAC webhooks, embedded signing, ICP-Brasil support, evidence export, DPA, and data location.
Obtain a B3 Digitas proposal separating setup, integration, certification, licensing, custody, settlement, support, and usage fees.
Map the architecture to at least one current Stellar Integration List building block that is material to the delivery scope.
Provide traction evidence and a repository-level distinction between reused Base functionality and new Stellar work.