Blockchain Events
Events being logged by GoodDAPP
Events are the Solidity abstraction on top of the EVM's logging functionality.
Events are inheritable members of contracts. When you call them, they cause the arguments to be stored in the transaction’s log - a special data structure in the blockchain. These logs are associated with the address of the contract, are incorporated into the blockchain, and stay there as long as a block is accessible. The Log and its event data is not accessible from within contracts.
GoodDAPP currently supports subscription to events through polling. Using
GoodWallet
pollForEvents
method, we can listen for logs in an almost real time manner. pollForEvents
is periodically polling for events like the specified event (filters by the specified event) up to the current blockchain block, and perform callback on them.goodWallet.pollForEvents(
{
event: 'Transfer',
contract: goodWalletContract,
fromBlock,
filterPred: { from: address }
},
(error, events) => log.debug('send events', { error, events })
)
pollForEvents
receive a callback which processes the list of events received from the filtered query.- 1.For
Transfer
funds from the account. - 2.For
Transfer
funds to the account.
In both cases, events are polled from the latest block that was not polled before (starting from the block the user was created and advancing). Once these events were filtered (found) by the client:
- Their receipts + Logs are being loaded from the Blockchain. The receipts + Logs object of each event are sent to the event subscriber. Subscribers to "transferFrom" are subscribing to
receiptUpdated
flag, and to "transferTo" are subscribing toreceiptReceived
flag. - Subscribers to "send" / "recieve" (accordingly) and
balanceChanged
flags are invoked also.
Account balance is updated after a
Transfer
(from or to) event is processed. As well, entitlement (amount to be claimed) is re-queried and updated accordingly.All the funds movement between accounts, to/from the current account are listed in the Dashboard's feed list.
Contracts being used by GoodDAPP logs different information in the form of events.
The list of contracts that GoodDAPP is aware of:
- when: During deployment/migration process, in the G$s minting phase. It's a one-time event.
- where: Emitted when the
GoodDollar.initialMove()
method is called and successfully executed.
- when: Every time a user Sends (Transfers) G$s to an account.
- where: In Send flow, user is able to transfer directly to an account by calling
GoodDollar.transfer()
specifying destination address, email, mobile or username.
from: who sent the G$
to: to whom the G$ was sent
value: the amount of G$ (in wei) being transferred
- when: Every time a user generates a link to share G$s in Send screen.
- where: In Send flow, user is able to generate a link to later be withdrawn by calling
GoodDollar.transferAndCall()
.
from: who sent the G$
to: to whom the G$ was sent
value: the amount of G$ (in wei) being transferred
data: encoded ABI to be called after G$ transfer
- when: Every time a Transfer is done.
- where: In Send flow, user is able to send G$s to another wallet by specifying its address, email, mobile or username, or by generating a link to later be withdrawn by calling
GoodDollar.transfer()
,GoodDollar.transferAndCall()
.
fee: fee being charged for the transaction (in wei).
And transferred to the GoodDollarReserve contract.
burned: fee being charged for the transaction (in wei).
And burned if transaction was successfull.
- when: During deployment/migration process.
- where: At contract deployment step, previous owner is set to
0x0
. And at the end of the migration process, ownership is transferred to theGoodDollarReserve
contract.
previosOwner: address of the previous owner.
The one who requested the ownership transfer.
newOwner: addres of the new owner.
- when: During deployment/migration process.
- where: At contract deployment, account used to deploy contract is being assigned. During migration
GoodDollarReserve
contract is also added.
account: the address of the contract/account who can mint.
- when: During migration process.
- where: During migration, after adding
GoodDollarReserve
, the deployer account is being removed. **
account: the address of minter to be removed from minters list.
- when: Not being used.
- where: Not being used.
owner: account that approves an amount of tokens to be spent by the 'spender'.
spender: account approved to spent an amount of tokens on behalf of the 'owner'.
value: amount of tokens approved to be spent by the 'spender'.
- when: When a transfer of G$s is being made to a contract that don't have
onTokenTransfer
method. - where: In the ÐApp, when sending directly to an address.
from: address making the transfer of G$s.
to: address to where the G$s where sent.
value: the amount of G$s being transferred.
- when: During deployment process.
- where: At deployment step, when class constructor is called.
account: the address of the contract's signer.
- when: Not being used.
- where: Not being used.
account: the address of the contract's signer to be removed.
- when: During deployment/migration process.
- where: At contract deployment step, previous owner is set to
0x0
. And at the end of the migration process, ownership is transferred toRedemptionFunctional
contract.
previosOwner: address of the previous owner.
The one who requested the ownership transfer.
newOwner: addres of the new owner.
- when: During migration process. And every time a new user is validated in GoodDAPP.
- where: During migration
GoodDollar
,GoodDollarReserve
andOneTimePaymentLinks
are added to the list. During application lifetime, when a user has been validated (email, mobile and Face Recognition).
account: address added to the validated list of GoodDAPP accounts.
- when: Not being used.
- where: Not being used.
account: address removed from the validated list of GoodDAPP accounts.
- when: During deployment/migration process.
- where: At deployment step, when class constructor is called, sets account used to deploy the contract.
account: address added to the admin list.
- when: Not being used.
- where: Not being used.
account: address removed from admin list.
- when: When a deposit is being made from the ÐApp.
- where: In Send flow, if user generates a link to share G$s, the amount specified will generate a deposit to the contract.
from: account that deposits G$s.
hash: identifier for the amount being deposited.
amount: the amount of G$s being deposited.
- when: When a withdraw is being made from the ÐApp.
- where: Accessing the withdraw link being generated by Send -> Generate Link. Or by scanning, in the Receive flow, the QR code generated from the Sender
from: address that generated the deposit to be withdrawn.
to: address that excecuted the withdraw.
hash: identifier for the amount being withdrawn.
amount: the mount of G$s being withdrawn.
- when: During deployment process.
- where: At deployment, ownership is transferred to the deployer account.
previosOwner: address of the previous owner.
The one who requested the ownership transfer.
newOwner: addres of the new owner.
- when: When a user that generates the deposit decides to cancel it.
- where: Not being used.
from: address that cancels the deposit.
hash: identifier for the deposit.
amount: amount being cancelled.
- when: When user claims its G$s.
- where: In the ÐApp, when user has G$s to claim, it can go to the Claim flow and receive the G$s after making a Face Recognition validation.
by: registered address that claims G$s tokens.
total: amount of G$s being claimed.
- when: During deployment process.
- where: At deployment, ownership is transferred to the deployer account.
previosOwner: address of the previous owner.
The one who requested the ownership transfer.
newOwner: addres of the new owner.
Last modified 1yr ago